Feature request: Finer grained bug access control knobs
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
Our community just moved to track bugs in Launchpad and we're still learning as we go along. I was not sure if to ask this as a question, or report it as a feature request. I opted for the feature requests.
Use case: Sometimes users can get a little bit exuberant and overstep their competence. In most cases this is benevolent enthusiasm and it can be channeled, but sometimes there could also be a troll. What can be done about disruptive behavior other than dealing with it on a case by case basis and manually fixing the damage?
I notice that currently *every* registered LP user has full edit access to the following fields in *every* ticket for *every* publicly tracked project:
* Summary
* Affects
* Status
* Assigned to
* Bug description
* Privacy settings
* Tags
I don't think that *anybody* should have the right to *fully* change *all* of these fields, but you may think different.
The solution IMHO is finer grained controls on the https:/
Starting from the easiest extreme: add a list of banned users. So much for trolls.
For the tracker fields, add a table listing fields in the row, and the following user groups in the columns:
1. anybody logged in into LP
2. the user who filed the report / comment
3. the bug supervisor
4. the tracker owner
For each combination of row/column add a widget to determine what access rights are granted ti the group identified in the column over the field identified in the row. In most cases, a checkbox will suffice, although I've had a developer telling me that he does not want to see anybody changing the status or the importance of a ticket.
I can see a good reason to let anybody change the status of a ticket from "Incomplete" to "New" when they add new information; but I would not want anybody to change the status of a ticket to "fix committed" or "fix released"; nor would I want to see anybody fiddling with assignment other than for him/herself.
These even finer grained controls can not be satisfied with a simple chekbox, and the effort to implement them is probably big, so how about just focusing on the low hanging fruits and just implement a "banned" list and a yes/no kind of access control to the different fields/groups?
For instance, I would not let *anybody*
| Robert Collins (lifeless) wrote | #1 |
| Changed in malone: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| summary: |
- Feature Request: Finer Grained Access Control + Feature request: Finer grained bug access control knobs |
| description: | updated |
Hi, thanks for raising this. I wonder if we have enough docs on help.launchpad.net about access controls in the bug tracker. I suspect we don't - perhaps you could file a separate bug about that?
Anyhow, we certainly don't permit full access to all fields. We have hard coded role based security which limits what fields can be changed, and to what value.
For instance, 'assigned to' - unprivilieged users can only assign bugs to:
- themselves
- teams they are in (and this one is under discussion at the moment)
We have two goals around this; the first is that its important to us that Launchpad not become balkanized with every project having a very different feel for its bug database : we believe that there are sufficiently common needs across projects that our default behaviours should work well. (And we're improving our defaults over time).
Secondly, we do want to meet each projects needs, without compromising the understandability of Launchpad. So an ACL matrix is something we would hesitate to implement - it would be very hard to understand and remember for many people. Thats not to say we can't and won't do it - just that this would be a last recourse, and we don't think we're there yet.