⚓ T42497 Add editbugs user right to legitimate Bugzilla accounts

So I can generate a list of users, and a list of users in the "editbugs" group. We have 16085 users in total, of which 14591 are in the "editbugs" group. That makes 1494 users that are not in the group.

The simplest way I can think of adding these users to the group is using the same regex that allows everyone to set self-whines, which is .* in the User RegExp field of https://bugzilla.wikimedia.org/editgroups.cgi?action=changeform&group=7 but I'm not sure how it was done previously - I'll ask around.

sumanah wrote:

I did the same kind of diff and then took half an hour to go through and give editbugs to the accounts of about a hundred people whose email addresses I could verify (by looking at my own email archives). For example, I checked to make sure WMDE, WMF, and Wikia personnel had editbugs, and I kept my eyes out for the names and addresses of testers, community members, and developers I recognized.

I hope this will help reduce how much of a blocker this is, in the short term, but I know it's just a tiny bit of help.

Because it was such a headache to deal with the Bugzilla abuse, I'd like to wait before we give all new users the editbugs right upon account creation. Specifically, I would like to wait until the new fulltime Bug Wrangler starts, which will be in the first half of October.

I think we should not give the editbugs right to all non-privileged Bugzilla accounts yet, until someone does a little due diligence to check whether any of them show signs of being vandals (one of the most important being that the account name is falsely that of another community member). I'm open to other ideas regarding what that due diligence should be, and would mildly prefer to discuss that in private email instead of here.

(In reply to comment #4)

I did the same kind of diff and then took half an hour to go through and give
editbugs to the accounts of about a hundred people whose email addresses I
could verify (by looking at my own email archives). For example, I checked to
make sure WMDE, WMF, and Wikia personnel had editbugs, and I kept my eyes out
for the names and addresses of testers, community members, and developers I
recognized.

Thank you very much for working on this.

sumanah wrote:

Hey Bug Wrangler (Andre). :) Let's talk about this sometime in the next week -- it's a classic risk mitigation tradeoff.

A central way to see all activity of a specific user in Bugzilla might help. Unfortunately there is nothing currently available in/for Bugzilla that I'm aware of (except for running a query which would only provide a buglist of tickets touched by a user - not very helpful).

Personally I like https://bugzilla.mozilla.org/page.cgi?id=user_activity.html which is rather a hack. Its code (not a proper extension as far as I know) is at http://bzr.mozilla.org/bmo/4.2/annotate/head:/extensions/BMO/web/js/edituser_menu.js

I was told on IRC that
<LpSolit> andre: we plan to implement this feature in the core code

sumanah wrote:

Thanks for looking into this, Andre. Do we have any idea when they plan to implement "user activity" in core?

(In reply to comment #8)

Do we have any idea when they plan to implement "user activity" in core?

By earliest Bugzilla 4.6/5.0, but not definite. (4.4rc1 is the latest.)

In the meantime, I've set up email address regexes to let at least WMF/WMDE users automatically receive sufficient permissions. I'd love to extend this but doing this automatically requires email addresses as a criterion.

(In reply to comment #2)

This bug seems like a classic blocker to me. When people are unable to
effectively and efficiently use Bugzilla, it blocks development work.

The big majority of users can. Those users without "editbugs" permissions can ask and receive them (though we do not document how - that's something to change), or ask many other people to change some restricted fields in a bug report on behalf of them.
This is inconvenient but does not "block development work" in general.

Summary: I don't see a good way out of this situation.
Giving editbugs to everybody did not work out in the past, giving it automatically to a subset of users via an email address regex cannot be applied here, giving it manually to a subset of users likely won't scale (though we should challenge the word "likely" here), and we currently cannot access user activity data from other infrastructure tools (e.g. "user has a Labs/Gerrit account so we trust in Bugzilla too").

(In reply to comment #10)

Summary: I don't see a good way out of this situation.
Giving editbugs to everybody did not work out in the past, giving it
automatically to a subset of users via an email address regex cannot be
applied
here, giving it manually to a subset of users likely won't scale (though we
should challenge the word "likely" here), and we currently cannot access user
activity data from other infrastructure tools (e.g. "user has a Labs/Gerrit
account so we trust in Bugzilla too").

MZMcBride: Do you have any other proposals?

(In reply to comment #11)

MZMcBride: Do you have any other proposals?

Maybe we could do a bit like MediaWiki does with autoconfirmed, i.e. automatically add the bit to all accounts older than X with more than Y actions of some sort? Ideally automated, such a rule assisted by a query would make manua additions of the bit easier and more reliable.

(In reply to comment #10)

Giving editbugs to everybody did not work out in the past [...]

I'm not sure I'd agree with this. It worked out for the most part in the past, as I understand it. Was there some abuse? Of course: any open system will eventually see some abuse (spam, vandalism, etc.). But it may make sense to try reverting to the previous setting (i.e., granting new users "editbugs" automatically and only removing it as necessary and appropriate). This is largely the same approach we take on the wiki.

I haven't been around for too long, so what I'm aware of:
http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/057197.html
http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/057233.html

(In reply to comment #14)

I haven't been around for too long, so what I'm aware of:
http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/057197.html
http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/057233.html

I'm having a very difficult time understanding what you're trying to say in this comment. It looks like someone changed a few bug properties in December 2011 (in good faith, we assume). This can't possibly be a justification for restricting the "editbugs" permission from every new account...

I tried to provide ONE example of the problem, not a complete list. :)
I don't have the time to skim again through the last years of wikitech-l archives to list each time something similar happened...

(In reply to comment #13)

This is largely the same approach we take on the wiki.

On the wiki there's rate limiting and a way to easily undo lots of changes (even if only through cobbled-together scripts). It sounds like Bugzilla has neither of those things at the moment. Someone should fix that. :-)

(In reply to comment #15)

I'm having a very difficult time understanding what you're trying to say in
this comment. It looks like someone changed a few bug properties in December
2011 (in good faith, we assume).

I don't know about those messages specifically, but the problem was that occasionally some address of the kind tim_starling@yahoo.com would mark hundreds of bugs fixed or reopened or assigned, which then someone had to revert all across bugzilla.
I remember this happening several times and each of them I received dozens of notifications, very confusing at first (especially if you don't know they were impersonating accounts), so that *was* major disruption.

Again, I have no idea what would be the best way to deal with the problem; and sure, it's nothing irreversible so we could as well just restore editbugs for all and see what happens: but this doesn't mean the problem doesn't exist.

This change is actively disrupting development work in Bugzilla:

bug 55980 comment 2
bug 56210 comment 4

I'd like to see a plan put in place to fix this issue. I'm strongly reminded of the "download attachments" bug in which a problem is needlessly being created.

Plans and ideas are welcome.
(To call something "needless" it requires to know the background though.)

Perhaps users without editbugs rights should be shown a link "Why can't I change these fields?" in the corner of the bug fields, which takes them to a help page on mediawiki.org or meta where they can read about the editbugs permission, and what criteria they need to meet to get it.

Then they e-mail the Bugmeister to ask for permissions and explain why they meet the criteria (or file a request on a mw.o "requests for BZ rights" page - but then there is a risk of the request being left neglected or ignored if BZ admins forget to check the page).

This is similar to what bugzilla.mozilla.org uses - if you want canconfirm rights there, you need to e-mail their admin (Gerv) with links to three good bugs that you have filed (that have been confirmed, and not invalid/wontfix/dupes/etc). They seem to be a bit more selective about who they give editbugs to (although I got it without asking for it - possibly by mistake).

(In reply to comment #21)

Good grief, no. The last thing we need is additional bureaucracy.

Based on the evidence presented here, the problem is limited while the "solution" is painful and unnecessary. In other words: this seems like a classic case of the cure being being the worse than the disease. Though if you feel otherwise, I'd be interested to know why. I appreciate you trying to find a solution here, but I don't think setting up a middle man is reasonable.

(In reply to comment #22)

(In reply to comment #21)

Good grief, no. The last thing we need is additional bureaucracy.

Based on the evidence presented here, the problem is limited while the
"solution" is painful and unnecessary. In other words: this seems like a
classic case of the cure being being the worse than the disease. Though if
you
feel otherwise, I'd be interested to know why. I appreciate you trying to
find
a solution here, but I don't think setting up a middle man is reasonable.

Indeed.

I'd suggest we could go back to giving all registered users editbugs like we did for years and years until somebody/some people panicked after the last spam attack and decided to zomglockdown everything.

We dealt with spam users just fine in the past. What supposedly changed?

This settings change is actively harming development efforts. I received yet another request, this time via e-mail, for a Bugzilla user to be assigned to a bug (in this case, bug 56121).

This settings change needs to be either reverted or we need to find an acceptable workaround. Locking out every new developer is not an option.

The way forward is probably discussing this on wikitech-l@ and finding consensus - see comment 1 and comment 14 for the previous discussions on wikitech-l@ that led to the current situation.

(Let me just note that I had been asked by e-mail to assign bugs to people too.)

If it's so hard to change the current situations due to some unspecified "vandalism", then we should probably just give out 'editbugs' more widely – I'd say to anyone who has submitted a valid bug, fixed one, or posted useful comments on a few. This would probably require letting more people give out the right, though, unless one/some of the Bugzilla admins are willing to take care of that (we have people reading/scanning all bugmail anyway already, don't we?).

(Posting here in addition of wikitech-l for the record)

You are getting suddenly these emails from a group of students at
http://foss.amrita.ac.in because a mentor told them to do so. We have
explained the right process to them (asking in the bug report itself
instead of sending private emails).

This is what Andre and me found out after asking to some of these
potential volunteers. They are getting the bugs assigned, as requested.
Let's see how many have the skills and determination to resolve the bugs.

After reading all this thread [1], I would be cautious changing the current
setup. New users can't assign bugs to them, but nothing is stopping them
to comment their intentions on the report itself, and actually fix the
bug. If a potential contributor doesn't understand this (yet), there is
also a chance that s/he won't be ready (yet) to fix the bug either,
because that will probably require understanding other, more complex steps.

This might be one of those barriers that happen to be useful to
understand better the complexity of a first task. I'm not sure we would
get a significant benefit by removing it, even if we wouldn't get any of
the vandalism that caused the introduction of the barrier in the first
place.

[1] Starting at http://lists.wikimedia.org/pipermail/wikitech-l/2013-November/072899.html

Andre: can you add "editbugs" to Tony Thomas' account, please? He currently can't assign bugs to himself.

done

bug 56359 comment 23

Andre: Wasn't it decided to make the editbugs user group viral? Is that possible? If so, we just need to document it and then we can resolve this bug, I think.

(In reply to comment #30)

Andre: Wasn't it decided to make the editbugs user group viral? Is that
possible? If so, we just need to document it and then we can resolve this
bug, I think.

bug 59853 comment 3

(In reply to MZMcBride from comment #30)

Andre: Wasn't it decided to make the editbugs user group viral?

I'm still waiting on an answer to this question.

(In reply to MZMcBride from comment #32)

(In reply to MZMcBride from comment #30)

Andre: Wasn't it decided to make the editbugs user group viral?

I'm still waiting on an answer to this question.

While you're at it, MZ, you could check the bugzilla docs/bugs/forums and report back if such a configuration is possible and how. :)

(In reply to MZMcBride from comment #30)

Wasn't it decided to make the editbugs user group viral? Is that possible?

http://lists.wikimedia.org/pipermail/wikitech-l/2013-November/072960.html

(In reply to Andre Klapper from comment #34)

(In reply to MZMcBride from comment #30)

Wasn't it decided to make the editbugs user group viral? Is that possible?

http://lists.wikimedia.org/pipermail/wikitech-l/2013-November/072960.html

Yes, but what does it take then? From that email it looks like there are no obstacles, of there is any I don't understand which it is.
Maybe you meant that you can't just add a permission "addeditbugs" to the existing "editbugs" group, but instead you need another group and hence someone will need to add all current editbugs users to that group? If so, can you start by creating this group? Then we can worry about who's going to do the DB query. :)

Users can be members of groups (e.g. editbugs) and there are two flags: You could have editbugs permissions yourself, and you could have rights to grant / hand out these permissions also to others.

There is no way to recursively and automatically give out editbugs permissions so users who have received editbugs permissions can also hand out editbugs permissions to other users, plus Bugzilla provides no UI to query for users who have editbugs permissions but cannot hand out editbugs permissions so they are hard to find.

(In reply to Andre Klapper from comment #36)

Users can be members of groups (e.g. editbugs) and there are two flags: You
could have editbugs permissions yourself, and you could have rights to grant
/ hand out these permissions also to others.

Good, what does it take to enable the latter?

There is no way to recursively and automatically give out editbugs
permissions so users who have received editbugs permissions can also hand
out editbugs permissions to other users,

We'll live with it or refresh permissions in a few years from now.

plus Bugzilla provides no UI to
query for users who have editbugs permissions but cannot hand out editbugs
permissions so they are hard to find.

Not a problem per above.

(In reply to Nemo from comment #37)

Good, what does it take to enable the latter?

A user with either admin or editusers rights who goes to the editusers.cgi page, queries and finds the user account, and enables the "grant to others" checkbox in the "editbugs" group column for that user account.

(In reply to Andre Klapper from comment #38)

A user with either admin or editusers rights who goes to the editusers.cgi
page, queries and finds the user account, and enables the "grant to others"
checkbox in the "editbugs" group column for that user account.

Ok, is the DB schema documented? Who can write a query to do this for all editbugs accounts?

(In reply to Nemo from comment #39)

Ok, is the DB schema documented?

Not what I would call "documented": There's http://www.ravenbrook.com/tool/bugzilla-schema/ and https://bugzilla.mozilla.org/show_bug.cgi?id=913190

For what is worth, in Phabricator this problem can be solved in a simple way:

Create a project "Task Editors" with the policy that only the members of the project can add new members.

Set a policy for tasks (Maniphest) allowing to edit bugs only to admins and the members of the project "Task Editors".

Done. If needed, you can set more precise policies to the teams you want. See what we have in http://fab.wmflabs.org :

POLICIES
Can Use Application
Public (No Login Required)

Can Configure Application
Administrators

Default View Policy
Public (No Login Required)

Default Edit Policy
All Users

Can Edit Task Status
All Users

Can Assign Tasks
All Users

Can Edit Task Policies
Administrators

Can Prioritize Tasks
All Users

Can Edit Task Projects
All Users

Can Bulk Edit Tasks
All Users

See also: Set up repositories, projects, permissions, etc. http://fab.wmflabs.org/T64

Fixed by Chad! \o/
http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076723.html
https://www.mediawiki.org/w/index.php?title=Bugzilla&diff=next&oldid=994911

Add editbugs user right to legitimate Bugzilla accounts
Closed, ResolvedPublic
Actions

Description

Details

Event Timeline

Add editbugs user right to legitimate Bugzilla accountsClosed, ResolvedPublicActions

Description

Details

Event Timeline

Add editbugs user right to legitimate Bugzilla accounts
Closed, ResolvedPublic
Actions