Last modified: 2008-04-05 16:44:38 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 T9011, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7011 - Update block log when renaming an account
Update block log when renaming an account
Product: MediaWiki extensions
Classification: Unclassified
Renameuser (Other open bugs)
All All
: Normal enhancement with 14 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 12926 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-08-14 22:15 UTC by Darkoneko
Modified: 2008-04-05 16:44 UTC (History)
2 users (show)

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

Logging table fix (550 bytes, patch)
2007-01-18 07:50 UTC, Titoxd
Stab 2 (1.22 KB, patch)
2007-01-18 08:11 UTC, Titoxd
Whitespace fix (1.21 KB, patch)
2007-01-18 08:18 UTC, Titoxd

Description Darkoneko 2006-08-14 22:15:14 UTC
If I rename an user that happen to be currently blocked, the blocklist doesn't
follow : there's still the block with the old name (a fanthom block, since it
does not correspond to an existing account anymore).

For exemple
*aaaaa is blocked
*aaaaa is renamed to bbbbb
->"aaaaa" still appears unchanged in the block list

You ask, why the hell renaming a blocked account ? well because, it's because
they're containing insults (often against sysop, religion, ...)

Comment 1 Titoxd 2007-01-18 07:48:27 UTC
This requires the following SQL statement:

UPDATE `$DBprefix_logging` SET `log_title` = '(new username)' WHERE `log_type` =
'block' AND `log_title`='(old username)'

I'll be committing a patch shortly...
Comment 2 Titoxd 2007-01-18 07:50:46 UTC
Created attachment 3087 [details]
Logging table fix

I'm not sure how expensive this is, but here's my first patch. Enjoy! ;)
Comment 3 Titoxd 2007-01-18 08:11:57 UTC
Created attachment 3088 [details]
Stab 2

Using Title::getDBkey(), as it should be
Comment 4 Titoxd 2007-01-18 08:18:16 UTC
Created attachment 3089 [details]
Whitespace fix

Remove artifact caused by IDE
Comment 5 Brion Vibber 2007-01-24 07:26:29 UTC
Would make log inaccurate. WONTFIX.
Comment 6 Titoxd 2007-01-24 08:01:00 UTC
Reopening the bug per Brion on #wikimedia-tech

There's some general issues with logs and deleted/moved stuff. One way to fix
those problems is by modifying the logging table to include a foreign key with
the page id or the user id of a page or user, respectively. Then, a block can be
looked up via a log_user_id column, instead of the log_title column, which would
give out all the blocks on an account regardless of renames, and would not
require tampering with logs.

Related to this is keeping the revision_id of a deleted page, keeping the logs
of protected pages with the page, and other assorted Bag O'Stuff. More
suggestions include changing Special:Log to include more text boxes, so that
typing "User:Titoxd" in the page field does not become necessary anymore. That
could potentially be transparently to the user. 
Comment 7 Titoxd 2007-01-24 08:11:20 UTC
For future reference: related to this issue are bug 8296 and bug 2919.
Comment 8 chickbowen 2007-02-26 01:16:09 UTC
The same problem has come up with the user rights log.  For sysops who change
usernames, the user rights log stays on the old username.
Comment 9 secretlondon 2007-05-05 03:02:18 UTC
This is causing us problems. (see for discussion). 

We cannot tell from the logs whether a user has previously been renamed or not -
and their block log stays with the old name. This makes it hard for admins to
know how long to block someone for as if you are renamed you lose your history.
We also can't pick up renaming addicts.
Comment 10 Raimond Spekking 2008-02-05 17:58:24 UTC
*** Bug 12926 has been marked as a duplicate of this bug. ***
Comment 11 Aaron Schulz 2008-04-05 16:44:38 UTC
Done in r32816

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