launchpad-dev team mailing list archive

[Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx>]

On Fri, Sep 17, 2010 at 12:05 PM, Curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> 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