Last modified: 2014-07-19 22:30:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22954, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20954 - Local contribution lists of globally hidden accounts no longer visible to stewards
Local contribution lists of globally hidden accounts no longer visible to ste...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
1.24rc
All All
: Normal major with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 20476
Blocks: revdel SWMT
  Show dependency treegraph
 
Reported: 2009-10-02 15:58 UTC by Jesse (Pathoschild)
Modified: 2014-07-19 22:30 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jesse (Pathoschild) 2009-10-02 15:58:55 UTC
Global hiding was recently changed so the usernames are only visible to oversighters. This is problematic because it prevents stewards from reviewing local accounts they themselves hid, and because username hiding should logically trigger hideuser (RevisionDelete block feature) rather than a username oversight.

Please use the hideuser feature (so that the names are visible to administrators) rather than oversight.
Comment 1 Mike.lifeguard 2009-10-02 16:16:56 UTC
(In reply to comment #0)
> username hiding should
> logically trigger hideuser (RevisionDelete block feature) rather than a
> username oversight.

Andrew has said this won't be how it is implemented at bug 14476 comment 18

> Please use the hideuser feature (so that the names are visible to
> administrators) rather than oversight.

Administrators cannot see usernames hidden with hideuser, nor should they be able to.
Comment 2 DerHexer 2009-10-02 16:47:30 UTC
Changed summary to the given problem.
Stewards cannot see the local contribution lists of these users whose user names they have hidden. That is quite annoying because stewards normally first hide the accounts globally and locally before they revert their edits. While the edits are still visible via API (which is another bug) they are not any longer visible onwiki. They just can be seen when we have the global rights deleterevision and suppressrevision which we shouldn't have at the same time because of transparency issues. So please switch that combination/access to something more appropriate (global right suppressionlog or a new one which could be related to [[bugzilla:20476]] ).
Comment 3 Jesse (Pathoschild) 2009-10-02 17:09:05 UTC
This is actually caused by automated local-hiding by scripts when global hiding; see bug 20476 (Create new right/permisson to view hidden revision) and bug 19199 (Granularize RevisionDelete user rights).

Marked invalid.
Comment 4 DerHexer 2009-10-02 17:22:23 UTC
Erm, it doesn't matter if these accounts are hidden automatically or not: Local oversights manually hide user names (which include libellous or unpublished informations according to our current oversight policy) from all users [except oversights and stewards] since months, and we steward did and do that, too. That stewards got annoyed, hiding hundreds of those user names by hand (because [[bugzilla:14476]] has not been fixed since months [now years]) and decided to write themselves a script to help them do that work, is independent from that case here, that with the software update these stewards cannot any longer see the contributions of those users whose user names they have hidden (manually, semi-automatically, whatever).
Comment 5 DerHexer 2010-03-29 11:50:45 UTC
Anyone interested in fixing that bug so that stewards do not have to stay global oversights to see contributions of hidden accounts? Stewards are suppossed to change their rights because of transparency issues when doing oversight actions. Most of them still do that but we cannot control if anyone did one without changing it. That is not acceptable. So I again beg to our developers to fix that bug as soon as possible.
Comment 6 Church of emacs 2010-03-29 16:54:11 UTC
Splitting the suppressrevision right into "peform action" and "review action" rights would solve this problem.
I suggest creating a new user right "reviewsuppressed" which makes it possible to review suppressed revisions/usernames/etc. "suppressrevision" would be the right associated with changing those settings (suppressing/unsuppressing).
Oversights would get both rights, Stewards the "reviewsuppressed" right.

Sounds good?
Comment 7 Victor Vasiliev 2010-03-29 17:10:20 UTC
(In reply to comment #6)
> Splitting the suppressrevision right into "peform action" and "review action"
> rights would solve this problem.
> I suggest creating a new user right "reviewsuppressed" which makes it possible
> to review suppressed revisions/usernames/etc. "suppressrevision" would be the
> right associated with changing those settings (suppressing/unsuppressing).
> Oversights would get both rights, Stewards the "reviewsuppressed" right.
> 
> Sounds good?

Sounds good, though "re" in "reviewsuppressed" looks redundant. I'll do it (I'm bug assignee anyway)
Comment 8 Leinad 2010-09-14 12:37:49 UTC
Bug20476 is very similar, so I added to section "Depends on" (but maybe this bug should be marked as "Duplicate"?).
Comment 9 Bugmeister Bot 2011-08-19 19:13:00 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 10 Kudu 2011-09-01 20:13:21 UTC
(In reply to comment #8)
> Bug20476 is very similar, so I added to section "Depends on" (but maybe this
> bug should be marked as "Duplicate"?).

It's not a duplicate: #20476 is the change that's needed in the MediaWiki code, this bug is the local instance of the issue.
Comment 11 DerHexer 2012-11-08 20:52:29 UTC
Any news on this—for stewards—important bug?
Comment 12 Vogone 2014-07-19 22:19:54 UTC
Should be RESOLVED FIXED together with bug 20476 and after code is deployed to production. Feel free to reopen in case this requires further action.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links