would like limited access control for status field changes

Bug #126516 reported by Colin Watson on 2007-07-17
32
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

The Importance field is access-controlled such that (in Ubuntu) only the ubuntu-qa team can change its value. This is useful to stop inexperienced bug triagers from making a mess. However, inconsistently, we appear to allow anyone to change the value of the Status field. Now, it's certainly useful for anyone to be able to set bugs to Confirmed or whatever when enough information is present. The problem is that anyone can set a bug to Invalid, Won't Fix, or Fix Released, which has the effect of removing the bug from default searches. This is at least as harmful as incorrect changes to the Importance field, since it can cause valid bugs to get lost if the bug contacts aren't paying detailed attention to their bugmail.

In particular, we have a novice Ubuntu bug triager who has set a number of bugs to Fix Released lately with no justification and very little accuracy (he doesn't really understand the difference between Fix Committed and Fix Released, he doesn't understand the stable release updates process, and he seems to think that if a bug is old enough then it must be fixed by now). He isn't in the ubuntu-qa team, and my opinion is that he should not be allowed to set the Status field to values that cause bugs effectively to disappear.

Changed in malone:
importance: Undecided → Medium
status: New → Confirmed

personally, i'd say that that person needs to be spoken to, given a chance to change, and made sure what they understand what they're doing. If they keep doing it,

If they don't improve after this, I suggest one looks at filing a ticket for getting them thrown off launchpad, due to abuse.

Malicious abuse due to idiocy (and no wish to change) is still abuse, and should suffer the normal consequences of this.

Ubuntu may have a code of conduct, but it does not say "be nice to everyone, even people who are deliberately abusing your software, people and/or protocols".

Please don't lock down the whole of launchpad, for a couple of abusing bug triagers. There are better ways to stop them from abusing launchpad.

Brian Murray (brian-murray) wrote :

I agree that social pressures should be used to change inappropriate behavior but part of the problem is finding out if the system is being abused or misused. How many bugs will be inappropriately modified before any one notices?

John Dong (jdong) wrote :

I'd also like to see this implemented as an opt-in feature. The Backports project uses the In Progress status field to mark backports approved awaiting for archive managers to process, and lately I've had a few cases of triagers erroneously setting this status without my permission.

Dennis Schridde (devurandom) wrote :

Another proposed fix (for a default config maybe) is mentioned in bug #126516.

In reply to mpt's comment #2 on bug #202501 ("important way for volunteer contributors [..] to help out with projects", "how would projects learn which potential QA contributors *should* be granted access?"):
Everyone can write a comment on a bug. The newbie could eg. write "I can confirm this" or "I think it was closed in version X" or whatever. Then a maintainer would read it and could close it by means of his maintainer-power.

Micah Gersten (micahg) wrote :

This has become more of an issue now that the Status field can be changed with an AJAX call.

Deryck Hodge (deryck) wrote :

I'm going to take on the work of making Fix Released access controlled in the same way as Won't Fix. I'm not sure I agree we should do this for Invalid yet, but I'm open to being persuaded.

Cheers,
deryck

Changed in malone:
assignee: nobody → Deryck Hodge (deryck)
status: Triaged → In Progress
Deryck Hodge (deryck) wrote :

The work I did ended up only locking FIXRELEASED from unsetting, not setting. So I've opened bug 664096 about this issue, and will link the branches here against that bug. Sorry for the noise here.

Changed in malone:
status: In Progress → Triaged
assignee: Deryck Hodge (deryck) → nobody
Changed in malone:
assignee: nobody → Deryck Hodge (deryck)
milestone: none → 10.11
tags: added: qa-needstesting
Changed in malone:
status: Triaged → Fix Committed
status: Fix Committed → In Progress
Deryck Hodge (deryck) wrote :

The QA bot went crazy. I'll clean up the mess.

Changed in malone:
status: In Progress → Triaged
assignee: Deryck Hodge (deryck) → nobody
milestone: 10.11 → none
Deryck Hodge (deryck) on 2010-10-26
tags: removed: qa-needstesting

QA bot acted here because the r11754 commit message contained this bug number.

On Tue, Oct 26, 2010 at 10:07 AM, Deryck Hodge
<email address hidden> wrote:
> The QA bot went crazy.  I'll clean up the mess.
>
> ** Changed in: malone
>       Status: In Progress => Triaged
>
> ** Changed in: malone
>     Assignee: Deryck Hodge (deryck) => (unassigned)
>
> ** Changed in: malone
>    Milestone: 10.11 => None
>
> --
> would like limited access control for status field changes
> https://bugs.launchpad.net/bugs/126516
> You received this bug notification because you are subscribed to
> Launchpad Suite.
>

--
Ursinha (Ursula Junque)
<email address hidden>
<email address hidden>
--
Ubuntu - I am because we are
--
Linux user #289453 - Ubuntu user #31144

Robert Collins (lifeless) wrote :

lying to the deploybot to get it to ignore this (falls under 'must be able to edit things post commit')

Changed in malone:
assignee: nobody → Deryck Hodge (deryck)
tags: added: qa-ok
Changed in malone:
assignee: Deryck Hodge (deryck) → nobody
tags: removed: qa-ok
tags: added: qa-untestable
tags: removed: qa-untestable
tags: added: qa-untestable
William Grant (wgrant) on 2011-05-16
tags: removed: qa-untestable
Robert Collins (lifeless) wrote :

We do have limited access control now. I don't know if its sufficient to meet Ubuntu's needs yet.

Changed in launchpad:
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions