Add editbugs user right to legitimate Bugzilla accounts
Closed, ResolvedPublic

Description

As I understand it, the editbugs permission was removed from new accounts in response to some abuse of this Bugzilla installation.

Now there are a few hundred accounts that are missing this user right, most of which are likely legitimate accounts. From some of the comments I've read, this group of unfairly restricted user accounts apparently includes some Wikimedia Foundation staff. This needs to be fixed.


Version: wmf-deployment
Severity: major

bzimport added a project: Wikimedia-Bugzilla.Via ConduitNov 22 2014, 1:09 AM
bzimport set Reference to bz40497.
MZMcBride created this task.Via LegacySep 25 2012, 3:05 AM
Aklapper added a comment.Via ConduitSep 27 2012, 11:28 AM

Not sure either if this issue is a blocker per se.

For the records:
http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056479.html
http://lists.wikimedia.org/pipermail/wikitech-l/2012-May/060706.html

From some of the comments I've read

URLs welcome.

MZMcBride added a comment.Via ConduitSep 27 2012, 9:26 PM

(In reply to comment #1)

Not sure either if this issue is a blocker per se.

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

From some of the comments I've read

URLs welcome.

https://bugzilla.wikimedia.org/show_bug.cgi?id=29858#c3

Thehelpfulone or some other Bugzilla administrator can generate a list of accounts without the "editbugs" user right.

bzimport added a comment.Via ConduitSep 27 2012, 9:35 PM

Thehelpfulonewiki wrote:

(In reply to comment #2)

Thehelpfulone or some other Bugzilla administrator can generate a list of
accounts without the "editbugs" user right.

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.

bzimport added a comment.Via ConduitSep 28 2012, 12:29 PM

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.

MZMcBride added a comment.Via ConduitSep 29 2012, 12:29 AM

(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.

bzimport added a comment.Via ConduitOct 14 2012, 10:10 PM

sumanah wrote:

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

Aklapper added a comment.Via ConduitOct 26 2012, 9:31 PM

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

bzimport added a comment.Via ConduitOct 26 2012, 11:42 PM

sumanah wrote:

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

Aklapper added a comment.Via ConduitOct 29 2012, 9:18 AM

(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.)

Aklapper added a comment.Via ConduitFeb 26 2013, 3:23 PM

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").

Aklapper added a comment.Via ConduitJul 17 2013, 11:38 AM

(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?

Nemo_bis added a comment.Via ConduitJul 17 2013, 11:42 AM

(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.

MZMcBride added a comment.Via ConduitJul 17 2013, 2:34 PM

(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.

MZMcBride added a comment.Via ConduitJul 18 2013, 1:34 AM

(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...

Aklapper added a comment.Via ConduitJul 18 2013, 9:20 AM

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...

Emufarmers added a comment.Via ConduitJul 18 2013, 2:20 PM

(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. :-)

Nemo_bis added a comment.Via ConduitJul 18 2013, 5:25 PM

(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.

MZMcBride added a comment.Via ConduitNov 2 2013, 1:52 PM

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.

Aklapper added a comment.Via ConduitNov 2 2013, 9:28 PM

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

TTO added a comment.Via ConduitNov 5 2013, 2:38 AM

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).

MZMcBride added a comment.Via ConduitNov 5 2013, 2:53 AM

(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.

demon added a comment.Via ConduitNov 5 2013, 2:56 AM

(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?

MZMcBride added a comment.Via ConduitNov 6 2013, 2:10 PM

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.

Aklapper added a comment.Via ConduitNov 6 2013, 2:13 PM

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.

matmarex added a comment.Via ConduitNov 6 2013, 2:43 PM

(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?).

Qgil added a comment.Via ConduitNov 6 2013, 8:09 PM

(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

MZMcBride added a comment.Via ConduitDec 5 2013, 5:08 AM

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

Aklapper added a comment.Via ConduitDec 5 2013, 11:58 AM

done

MZMcBride added a comment.Via ConduitJan 2 2014, 6:34 AM

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.

MZMcBride added a comment.Via ConduitJan 14 2014, 6:21 AM

(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

MZMcBride added a comment.Via ConduitFeb 25 2014, 12:53 AM

(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.

Nemo_bis added a comment.Via ConduitFeb 25 2014, 7:49 AM

(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. :)

Aklapper added a comment.Via ConduitFeb 25 2014, 11:32 AM

(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

Nemo_bis added a comment.Via ConduitFeb 25 2014, 11:38 AM

(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. :)

Aklapper added a comment.Via ConduitFeb 25 2014, 2:45 PM

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.

Nemo_bis added a comment.Via ConduitFeb 25 2014, 4:13 PM

(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.

Aklapper added a comment.Via ConduitFeb 25 2014, 11:15 PM

(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.

Nemo_bis added a comment.Via ConduitFeb 26 2014, 10:01 AM

(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?

Aklapper added a comment.Via ConduitFeb 26 2014, 11:04 AM

(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

Qgil added a comment.Via ConduitMay 13 2014, 10:17 PM

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

  1. Create a project "Task Editors" with the policy that only the members of the project can add new members.
  1. 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

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.