On Fri, Sep 17, 2010 at 12:05 PM, Curtis Hovey <[email protected]> wrote: > On Fri, 2010-09-17 at 12:54 -0400, Curtis Hovey wrote: > ... >> Full and Partial Disclosure >> --------------------------- >> >> Launchpad will permit users to have full or partial disclosure to a private >> structure. The mechanism will be like a subscription. The owner can subscribe >> users and restricted teams to their structure or its items. Access to >> a structure gives the user access to all subordinate items. Subscription >> is not about notification in this case, it is about disclosure. > > bac: I think the term 'subscription' is fatally overloaded at this > point. Could you call it 'access' or something besides subscription? > A person doesn't really subscribe to a project but is granted access > to it. Unfortunately 'access' is closely tied to 'ACL' so that may be > a reason to avoid it. > > sinzui: I agree, and I first used the term access and realised I was > leading people down the ACL discussion again. We use the terms view and > traversal, and I tried to create terms for them without success. I > wasn't happy with "Permit" and "Grant" either, but I agree that > subscribe is wrong. This feature is about managing disclosure of > information. > >> * Full disclosure means user can view all aspects of the project. >> >> * The user can see private branches of code, bug reports, and >> personal private package archives (P3A) automatically. > > bac: The private PPA access may be sticky, given their use of tokens > and custom-generated .htaccess files. Not that it cannot be done, but > I'd suspect to see objections from Julian. > > sinzui: Launchpad traversal was invented so solve this very use case. > Users were given view and we know that is wrong. > >> * The user does not need to be subscribed to the specific item. >> >> * The user does not need to be a member of the bug supervisor team >> to gain access to a bug report (and will not receive unwanted email). > > bac: Will the bug supervisor team automatically be given access, as > is done now? > > sinzui: excellent question: I have an opinion, and am sure I am right, > but have not proposed that we fix the cluster of bugs already reported. > Namely. Changing a bug supervisor is impossible for large projects > because > * The new supervisor is not added the existing bugs...they do not > get access to private bugs :(. > * The old supervisor continues to get emails :( > * Having view on a private structure, or being an owner/driver for > the pillar (public or private) should suffice to access any bug > for the pillar. > * Certainly, being a supervisor should give you access to any bug > that affects the project, distro, or package. > * Consider the stupidity of malone right now, If a bug is report > on a project without a bug supervisor creates an email to the > owner...even if the pillar does not use Launchpad Bugs! We can > easily fix this rule to use the bug supervisor instead, and only > send the email if malone is official. > So I think that I do not need need to be a bug supervisor gain access to > bugs or to get bug mail (via a structural subscription). The bug > supervisor can change the status of bugs, just as the owner and driver > can (or should). We only need a bug supervisor rule is the role needs > different permission from drivers. I think drivers permissions are > broken though (that is a separate bug).
For public projects, it makes some sense to allow the project owner to lose access to an artefact. For example, if the owner is not subscribed to a private bug. However, for a private project, the owner will want to audit it, so this doesn't make sense. -Edwin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
