← Back to team overview

launchpad-dev team mailing list archive

Re: Describing access policies in bug and branch UI


On 30 November 2011 21:41, Martin Pool <mbp@xxxxxxxxxxxxxx> wrote:
> On 24 November 2011 05:12, curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
>> During a review of a branch that pertained to the disclosure feature,
>> William and I discovered that we really do not know what an all powerful
>> user like an admin would see when viewing a private apport bug. We also
>> did not know how the admin could change the bugs policy. Part of the
>> issue is that we had decided not to change the UI where possible, but I
>> think we really do want to change the UI for managing the disclosure of
>> bugs and branches.
>> We currently have two checkboxes, Private and Security that create 4
>> combined states:
>>    Public
>>    Public Security
>>    Private Security
>>    Private *something else*
>> Note that security is like a tag (as William says) because it classifies
>> the primary content of the bug. We often forget this when designing who
>> people will manage the disclosure pages. The security policy in the new
>> access mechanism honours the current behaviour...we actually mean
>> security data that is *also* private.
> Just to throw out another option, it does seem like you could migrate
> 'security' to actually being a tag.  That would perhaps simplify the
> user model, the ui, and the code.  The filebug code could still have a
> checkbox for 'this is a security problem' that makes the bug private
> and adds that tag.
> It would also make 'private because it's security related' a bit more
> consistent with 'private because it's being chewed by apport'.

Presumably we could automatically subscribe the security contact to
bugs tagged "security".

Right now, only people who can see the security bug can remove its
security status, right? What happens in a world where we have
disclosed (i.e. public) security bug reports? Who gets to remove the
security status/tag?

Matthew Revell
Launchpad Product Manager


Follow ups