On 24 November 2011 05:12, curtis Hovey <curtis.ho...@canonical.com> 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'. -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
