[Pulp-dev] AccessPolicy Model Advice ... input needed

[Matthias Dellweg]

I think, it would help me to understand if you could reiterate what
kind of policy this model holds. Is it the class level permission like
"Only admins can create new repositories."?
What kind of context does a lookup for these objects? Is it the
PermissionClass that carries a context containing an instance to the
view / viewset, or the request with the resolver_match?

If it is userfacing i would probably also go for option 1 with the hrefs.

On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <dkliban at redhat.com> wrote:
>
> Pulp 2 users would definitely be familiar with describing policies in terms of urls. The Pulp 3 REST API already uses the pulp_href field as the primary identifier. You should implement idea 1.
>
> On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>>
>> I need some design input. To store AccessPolicy data in the DB I think we want one Model where each instance is the access policy for a given viewset. I think this would be better than one Model per Viewset which would generate N tables for N viewsets with 1 instance of each which would be very strange and inefficient.
>>
>> So let's assume we have a simple definition like the one below. Each instance stores the policy for one viewset.
>>
>> class AccessPolicy(BaseModel):
>>     data = JSONField()
>>
>> So what second field can I add to this that would allow me to relate an instance of this model to a viewset. For example the FileRemoteViewset here: https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116
>>
>> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. /pulp/api/v3/remotes/file/file/.
>> Idea 2: Add a viewset = CharField(), and have it store values as classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'.
>>
>> I think Idea 1 makes the most sense because that's how our users think of it. I can't think of a good alternative. What do you think makes the most sense? What alternative ideas should we consider?
>>
>> If you have feedback please share it. I need to start into something to get it going tomorrow even if it's just Idea 1 for lack of an alternate proposal.
>>
>> Thanks,
>> Brian
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev