Last modified: 2014-07-19 22:30:04 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.
(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.
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]] ).
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.
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).
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.
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?
(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)
Bug20476 is very similar, so I added to section "Depends on" (but maybe this bug should be marked as "Duplicate"?).
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
(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.
Any news on this—for stewards—important bug?
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.
