Page MenuHomePhabricator

User rights log doesn't reflect removing of sysop rights
Closed, DuplicatePublic

Description

Author: Eugene.Zelenko

Description:
I restored one of the sysop recently after short period of inactivity on Commons. However I was not able to find log entry (and reason for) for removing his/her rights in user rights log. Probably such information is located in stewards (or meta) log, but I think will be good idea to duplicate it in local project log.

See http://commons.wikimedia.org/w/index.php?title=Special:Log&type=rights&user=&page=&pattern=&limit=100&offset=0 and search for Boricuaeddie.


Version: unspecified
Severity: normal
URL: http://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=rights&user=&page=User%3ABoricuaeddie

Details

Reference
bz12925

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:06 PM
bzimport set Reference to bz12925.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Logging isn't always terribly consistent, annoyingly enough. I still say the logging should be in the same transaction as the change . . .

Note that for steward actions, you're working across databases so that's not really possible. For most other things, a proper transaction wrapper *ought* to happen.

ayg wrote:

You're right. It seems that there *is* a proper transaction wrapper for locally-used Special:Userrights, from my testing just now. So it's not such an easy fix, I guess.

bugs wrote:

*** Bug 13081 has been marked as a duplicate of this bug. ***

FT2.wiki wrote:

Is there any way that transactions in global logs can be reflected also in local rights logs too?

Or at a pinch, that the header for local rights logs for a user can also contain a link to the global log for the same user with a note explaining this, for clarity?

"This log shows local rights activities only. For global rights, such as removal of sysophood, or grant or removal of checkuser, oversight or stewardship, please see the [LINK global log for this user]."

  • This bug has been marked as a duplicate of bug 4055 ***