← Back to team overview

launchpad-dev team mailing list archive

Re: Describing access policies in bug and branch UI


On 1 December 2011 13:38, Matthew Revell <matthew.revell@xxxxxxxxxxxxx> wrote:
> 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?

To clarify: I think it should still be the security team, even if the
security bug is public.

Matthew Revell
Launchpad Product Manager


Follow ups