launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08582
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
Canonical
https://launchpad.net/~matthew.revell
Follow ups
References