<div dir="ltr"><div dir="ltr">On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse <<a href="mailto:bmbouter@redhat.com">bmbouter@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm concerned if we don't make a change, here's the user experience I'm worried about.</div><div><br></div><div>1. User A creates repo 'rhel7'</div><div>2. user B can't see repo 'rhel7' because of queryset scoping</div><div>3. user B goes to create 'rhel7'</div><div>4. user B is told 'rhel7' already exists</div><div><br></div><div>Users should be able to use simple names. I don't know what the answer is to the import/export implementation conflict, but let's brainstorm some. For the benefit of our users, I don't think that implementation should interfere with this basic use.</div></div></blockquote><div><br></div><div>User B creates rhel7 because they're not allowed to see User A's rhel7. User B has a role added. Now User B gets to see two rhel7s.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Side note: from early on in Pulp3, pk's not names have been the primary identifier. I'm unclear on how we got away from that.<br></div></div></blockquote><div><br></div><div>I'm a little confused - unique=True and unique_together=() are in a fair number of models, in pulpcore and pulp_rpm.  Artifacts are identified by hash, so we don't duplicate them. Do different users get to upload the same Artifact, just because their RBAC roles are different?</div><div><br></div><div>One thing that maybe we need to think about - is RBAC in pulp about "mutiple logins for users controlled by one entity/organization/admin/company that 'owns' the pulp instance", or does it include "multiple organizations that should never know the others' users/content exists"? The first is multi-user, the second I've seen described as multi-*tenant*, and feels like more the usecase you're concerned about. in my head, a single pulp-instance might be multi-user, but *not* multi-tenant - mayhap that's wrong.</div><div><br></div><div>G</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 9:03 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I always understood the "lifting the uniqueness" as allowing to have<br>
the same name used for different resource types. So the new<br>
natrual_key (aka unique_together) would be ["name", "type"].<br>
<br>
On Tue, Jul 21, 2020 at 2:55 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br>
><br>
> Agreed.<br>
><br>
> David<br>
><br>
><br>
> On Tue, Jul 21, 2020 at 8:42 AM Grant Gainey <<a href="mailto:ggainey@redhat.com" target="_blank">ggainey@redhat.com</a>> wrote:<br>
>><br>
>> On Tue, Jul 21, 2020 at 8:14 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br>
>>><br>
>>> Does anyone else have an opinion? If not, I am going to start by writing a task to remove this name uniqueness constraint for repositories.<br>
>><br>
>><br>
>> Import/export relies on non-pulp_id-uniqueness to identify Things. I was assuming we were talking about adding pulp_type to the Repository uniqueness-constraint, so that a given name/type would be unique (which would require a single change to RepositoryResource)<br>
>><br>
>> If we're talking about just removing the uniqueness-constraint altogether, then life gets a lot harder.<br>
>><br>
>> G<br>
>> --<br>
>> Grant Gainey<br>
>> Principal Software Engineer, Red Hat System Management Engineering<br>
>> _______________________________________________<br>
>> Pulp-dev mailing list<br>
>> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
>> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
><br>
> _______________________________________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Grant Gainey</div><div>Principal Software Engineer, Red Hat System Management Engineering</div></div></div></div></div></div>