Restrict setting bug priority to editbugs users

RESOLVED DUPLICATE of bug 1518670

Status

()

--
enhancement
RESOLVED DUPLICATE of bug 1518670
18 years ago
a month ago

People

(Reporter: mozilla-work, Unassigned)

Tracking

({bmo-bug-quality})

Production
bmo-bug-quality

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [permissions:edit])

(Reporter)

Description

18 years ago
The way I see it, only the bug owner or the owner's manager (i.e. Someone with
the appropriate permissions) should be able to change priorities.  Even the
reporter shouldn't be able to set the priority a bug is at.
(Reporter)

Comment 1

18 years ago
Setting to P1 to prove my point.
Priority: -- → P1
Target Milestone: --- → Future
Traditionally Bugzilla has mostly allowed anyone to do anything.  Fixing that
general problem to the satisfaction of a whole range of system is a difficult
problem.
Severity: normal → enhancement
Priority: P1 → P3
-> Bugzilla product, Changing Bugs component, reassigning.
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Whiteboard: [permissions:edit]
Version: Bugzilla 2.12 → 2.12

Updated

16 years ago
OS: Solaris → All
Hardware: Sun → All

Updated

15 years ago
Depends on: 90619

Comment 4

14 years ago
The eclipse.org team would also like to see this enhancement.

As submitted by one of our committers:
Bug priorities are used by committers for planning purposes. They should not be
changed by submitters, which should use the severity field instead. It would be
great if there was a way to prevent less priviledged users from changing the
priority field. Since Bugzilla does not prevent them from doing it, it is a very
common mistake users make.

Updated

13 years ago
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---

Updated

12 years ago
Assignee: myk → create-and-change

Comment 5

8 years ago
Just to leave a link (although I don't hope much in the bright future for this bug) ... Red Hat bugzilla would welcome this as well. https://bugzilla.redhat.com/show_bug.cgi?id=456697

Comment 6

7 years ago
There is a patch in https://bugzilla.redhat.com/show_bug.cgi?id=495985#c24 which allows only a specific group to change priority/severity.
Might be worth to clean up and pick up, as I see such issues with non-dev reporters all over the place in the several Bugzillas that I triage in (bugzilla.mozilla.org being one of them) and this wastes a lot of time for developers getting tainted results when querying for high priority tickets.
CC'ing David as he is the downstream author.


(In reply to Matej Cepl from comment #5)
> https://bugzilla.redhat.com/show_bug.cgi?id=456697

"You are not authorized to access bug #456697." :)
Given the split nature of this bug, this may be better suited as an extension to Bugzilla.
Assignee: create-and-change → extension.ideas
Component: Creating/Changing Bugs → Extension Ideas
We say in https://bugzilla.mozilla.org/page.cgi?id=etiquette.html that changing priority unless you're a person working the bug or responsible for making decisions about priority is not allowed. It'd be nice to just implement that part of the CoC.

Given this bugs been quiet in the bugzilla component since 2014, I'm moving it to bmo.
Assignee: extension.ideas → nobody
Component: Extension Ideas → Bug Creation/Editing
Priority: P3 → --
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Summary: Anyone can change priority → Restrict setting bug priority to assignees, triage leads, and module owners on a product basis
Version: 2.12 → Production
:gijs, you pinged me about this this morning on IRC but I can't find the quote, would you mind dropping that in here?
Flags: needinfo?(gijskruitbosch+bugs)
Summary: Restrict setting bug priority to assignees, triage leads, and module owners on a product basis → Restrict setting bug priority to editbugs users
To summarize what :gijs wrote, as I remembered it from the home screen on my phone:

We use Priority = "--" to know that a bug has not been triaged (people triaging the stream of unconfirmed bugs should be setting the priority to "--" on those).

If someone sets Priority on a bug that goes into New status when they file it, and they aren't making a triage decision, then we have a situation where we think a bug is triaged, but it's not. 

We need a way to manage this. 

In the short term, I'm going to set up a nag to tell me about new bugs in Firefox that are filed with priority set so I can go back and clean up priorities. 

I'm going to assume that if you're a triage owner, you know enough to set priority on filing, but really, nobody else should be setting priority on bugs.

Comment 11

7 months ago
18:12:56 <@Gijs> emceeaich: have we considered having a way to find bugs where the reporter sets the priority?
18:16:19 <@Gijs> emceeaich: our current triage process basically assumes that we find all the incoming bugs based on them not having a priority, but sometimes bug reporters seem to arbitrarily pick a priority (which is sometimes higher, but sometimes also lower (!) than what we would pick) and bugs fall through the cracks.

I happened to notice this happened in bug 1473243, where someone filed a bug and then, afterwards, set it to P3 - I came across the bug when searching for dupes by just listing all Fx::Preferences bugs filed in the last 10 weeks, and was confused because that one hadn't turned up in our triage list/meetings...
Flags: needinfo?(gijskruitbosch+bugs)
I'm monitoring the number of bugs where priority is set by someone without editbugs when the bug is created. 

We could implement this, it may affect non-Firefox bugs, but we can review custom form instances and if non-editbugs users are filing bugs through custom forms that require a priority field and come up with a plan for them.

Closing this as a dupe of bug 1518670 which will enable rule-based restrictions on fields.

Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1518670
You need to log in before you can comment on or make changes to this bug.