We have a continuous problem where people interacting with newcomers never remember that most fields of bugs can't be edited by new users, and we tell people to do things like "just assign the bug to yourself" or "set the checkin-needed keyword and your patch will be checked in". This sucks, and education will only get us so far. It would be lovely to make these fields not require editbugs privileges so we could avoid this stumbling block.

r- for keywords being editable by anybody. However, once the user is made the assignee, he/she will be able to edit the keywords. How's that sound? Maybe we should also make it so that only bugs where the assignee is nobody@ can be picked up by users without editbugs, and they can only assign it to themselves originally, or something...

Those sound like perfectly acceptable restrictions to me.

I'm inclined to allow a user without editbugs to be able to make themselves the assignee, regardless of the existing value of the Assigned To field. We have many instances of mentored bugs where someone expresses interest, is assigned the bug and never follows through on fixing it, and the mentor doesn't get around to resetting the assignee.

(In reply to Josh Matthews [:jdm] from comment #3) > I'm inclined to allow a user without editbugs to be able to make themselves > the assignee, regardless of the existing value of the Assigned To field. We > have many instances of mentored bugs where someone expresses interest, is > assigned the bug and never follows through on fixing it, and the mentor > doesn't get around to resetting the assignee. I am not sure it is desirable to allow anyone to assign themselves a bug as then they will have the ability to edit any other field as they see fit. Such as closing a bug when they are not a developer, qa, triager or the reporter, changing whiteboard contents, etc. The following exclusions will apply as the still require explicit group membership based on BMO customizations 1. Certain custom fields such as tracking/blocking flags need specific membership. 2. The EXPIRED resolution is only settable by gerv. 3. You need at least canconfirm to mark a bug as FIXED 4. You need at least editbugs to reopen a resolved/verified bug 5. Canconfirm is really "cantriage"; users with canconfirm can also mark bugs as DUPLICATE, WORKSFORME, and INCOMPLETE. 6. Disallow reopening of bugs which have been resolved for > 1 year So accept for above the assignee can edit most aspects of a bug regardless of editbugs permissions. I could see possibly people assigning bugs to themselves just to circumvent the editbugs restrictions we currently have in place. dkl

(In reply to David Lawrence [:dkl] from comment #4) > 3. You need at least canconfirm to mark a bug as FIXED Er, what? That's just wrong. Should fix that. The assignee should definitely be able to resolve his/her own bug as FIXED. > So accept for above the assignee can edit most aspects of a bug regardless > of editbugs permissions. I could see possibly people assigning bugs to > themselves just to circumvent the editbugs restrictions we currently have in > place. I'd be ok with giving it a trial run. I don't think it would require that many changes to implement, and if it doesn't work out, we can back the changes out.

How about if you have enough privs to see the "new to Bugzilla" indicator that gets put on new people, then you also get a tooltip with a summary of what the user is allowed to change on the bug if you hover over their email address? Or even an additional indicator that says "(limited privs)" or something (which would give more details as a tooltip if you hovered it). That might solve the education problem and let people offer to do something instead of telling the user to do it themselves.

(In reply to Reed Loden [:reed] from comment #5) > (In reply to David Lawrence [:dkl] from comment #4) > > 3. You need at least canconfirm to mark a bug as FIXED > > Er, what? That's just wrong. Should fix that. The assignee should definitely > be able to resolve his/her own bug as FIXED. When the assignee resolve the bug as FIXED without the commit priv?

Here is an alternative suggestion for solving the problem outlined in comment 0. We could improve the error messages that the user gets when trying to do something they can't. I'm not sure if they already contain instructions on how to get a privilege upgrade, but they should. They should mention that their mentor for the bug would be a good person to vouch for them (in an unofficial sense) if they don't have a track record. The difficulty with loosening the permissions of who can do what is that the current ones have been developed through long experience of people who want to mess things up... So, for example, it used to be true that anyone could edit the CC list, but then people started vandalizing CC lists so we had to change it so you can only add and remove yourself without editbugs. If one could do a mass query for nobody@mozilla.org bugs, assign them to oneself, and then do another mass query to mess them up, that could be done in 5 minutes and would need unravelling by a DBA. I agree that educating users manually is a pain, so can we get Bugzilla to do that education for us? Gerv

(In reply to Gervase Markham [:gerv] from comment #8) > Here is an alternative suggestion for solving the problem outlined in > comment 0. We could improve the error messages that the user gets when > trying to do something they can't. generally users aren't given the option to do something when they can't. for example, if you can't mark a bug as FIXED, that status won't be present in the list. likewise, if you don't have editbugs, the ui displays the assignee as static text. > The difficulty with loosening the permissions of who can do what is that the > current ones have been developed through long experience of people who want > to mess things up. +1 > I agree that educating users manually is a pain, so can we get Bugzilla to do that > education for us? we could display a link to the 'upgrade permissions' page [1] to users who don't have editbugs on bugs which are assigned to nobody. [1] https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html

In my understanding, the education described by this bug report that is lacking is not the education of the newbies as to what they can't do (because that's obvious to them) but the education of the old-timers to tell them that the newbies can't do that stuff, because they don't know they can't and will tell them to in the bug (which just frustrates the newbies when they can't do something they've been told to do by someone they perceive as an authority figure in the community).

justdave: that's a good point! Perhaps the problem is that it's not obvious who has editbugs/canconfirm and who doesn't. In fact, for a normal user it may not even be possible to find out (without asking). Can we mark people who don't have privs, so when someone is interacting with them in Bugzilla, they might realise that they can't follow such instructions? I'm thinking of something along the lines of the (New to Bugzilla) annotation - perhaps (No Edit Privileges) or something a bit nicer-sounding? Gerv

sounds very reasonable and trivial to implement. i prefer justdave's wording in comment 6 of (Limited Privileges).

Comment on attachment 672800 [details] [diff] [review] patch v1 Review of attachment 672800 [details] [diff] [review]: ----------------------------------------------------------------- Only issue I see is that we are starting to get a lot of tags in that limited space and it is causing the date to get displayed irregularly. For example someone who is (New to Bugzilla) (First Patch) (Limited Permissions), this is causing things to get shifted around strangely. Screenshot coming. But r=dkl as this may not be that widespread yet but we need to think about it before we expand further. dkl

Good point; how can we mitigate that? "New to Bugzilla" implies "Limited Permissions", so perhaps we could only show Limited Permissions if New To Bugzilla doesn't apply? Gerv

So here's the problem - I am doubtful that merely adding another tag will alleviate the problem that caused me to file this bug. Education of users has not been successful so far; I was excited about the prospect of allowing users to assign bugs to themselves, since that addresses a core problem. Could we put some limits in place to alleviate the risk of this? Users without editbugs can only assign 1 bug per minute, or something like that?

(In reply to Gervase Markham [:gerv] from comment #15) > Good point; how can we mitigate that? "New to Bugzilla" implies "Limited > Permissions", so perhaps we could only show Limited Permissions if New To > Bugzilla doesn't apply? > > Gerv What if we combined and shorted such as: (New Limited User) where Limited is omitted if the user does have editbugs permissions. As gerv mentioned, New and unprivileged is basically the norm anyway. (In reply to Josh Matthews [:jdm] from comment #16) > So here's the problem - I am doubtful that merely adding another tag will > alleviate the problem that caused me to file this bug. Education of users > has not been successful so far; I was excited about the prospect of allowing > users to assign bugs to themselves, since that addresses a core problem. > Could we put some limits in place to alleviate the risk of this? Users > without editbugs can only assign 1 bug per minute, or something like that? Still but even after the minute has expired they would still be able to edit a bug that they would not otherwise be able to. Such as closing one they don't agree with or changing whiteboard entries that others are using for useful purposes. I still like the idea of users having to prove themselves somewhat before expanding on what they can do. dkl

Assuming people won't assume "Limited" applies to them and not their privileges, and take offence, that seems OK to me :-) Josh: I'm afraid we can tell you from sad experience that if we relaxed the controls, everything would be great for a few months, then some griefer would come along, mess up a ton of bugs, and cause the Bugzilla admins and DBAs to have to spend ages fixing it. And things would be locked back down as before. It should not be hard for Bugzilla users to know that not everyone has the abilities they have - whether it's to view a bug at all, edit a bug or whatever. Adding a marking makes it even easier for them to realise this. I'm happy to do some blogging to get the message across more if that helps. Gerv

(In reply to Gervase Markham [:gerv] from comment #18) > Assuming people won't assume "Limited" applies to them and not their > privileges, and take offence, that seems OK to me :-) Hopefully the title they see when they hover over the label will be more descriptive and there will be no confusion. > It should not be hard for Bugzilla users to know that not everyone has the > abilities they have - whether it's to view a bug at all, edit a bug or > whatever. Adding a marking makes it even easier for them to realise this. > I'm happy to do some blogging to get the message across more if that helps. I also vote we try the label approach for a while and see if that helps. If the problem still persists in the same amount or more, we can take another look at this issue and try to find a better server side approach. dkl

You could have fixed this bug without any patch by setting an icon for the editbugs group. Why reinventing the wheel?

This patch never landed, did it? I don't recall seeing any new tag. Sadness.

Refering to "nobody@mozilla.org" as default assignee & resulting confusion how to set yourself as assignee if you are a new contributor without editbugs: (In reply to Gervase Markham [:gerv] from comment #8) > We could improve the error messages that the user gets when trying to do something they can't. New contributors (means: Bugzilla accounts without editbugs/canconfirm) who want to work on a bugfix assume that they must be set as assignee before starting to work on a bug. As they don't have "edit | take" links for the assignee field (due to no editbugs/canconfirm), they *click* the current assignee ("Nobody") and are surprised that a "Compose email" window is opened, instead of some UI in the browser to set themselves as new assignee. So one idea in https://bugzilla.wikimedia.org/show_bug.cgi?id=61985 was to not render the mailto: URL for specific accounts (like nobody@) but render a link to a wikipage explaining the development process and Bugzilla group permission requirements instead. No idea if that's feasible though.

mailto: links may go away entirely soon - bug 218917. Gerv

given the age of this bug and other changes i'm going to wontfix this. it's apparent that currently mentors are shying away from assigning a bug to anyone who requests. assigning bugs to anyone who asks problematic because if the assignee is unable to work on that bug, resulting in stale but assigned bugs. bug 1128878 is tracking a system to automatically unassign these sort of stale bugs. another problem is caused when a bug isn't assigned to someone who has attached a patch by the mentor - a step which is easy to forget. bug 1135164 was fixed 3 months ago to display a warning when an unassigned patch has warnings. once the bug is correctly assigned to the patch author they will be able to set checkin-needed or other flags.