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 <dkli...@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 <bmbou...@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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev


_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Reply via email to