Last modified: 2011-01-25 01:02:33 UTC
Here, a block log entry was deleted, but the entry remains in RC. On Special:Log/block the action is crossed out. As well, the user had been blocked by a local sysop, then re-blocked using hideuser. Repeated attempts to hide the log entry with revision deletion were unsuccessful.
Created attachment 5990 [details] kowiki's Special:RecentChanges showing the account name
Created attachment 5991 [details] kowiki's Special:Log/block with account names redacted properly
Poking at Aaron, since he seems to be more or less responsible for revision deletion.
Was the block log entry manually hidden?
Yes, we tried several times to hide it manually. (But I suppose even blocking the user with hideuser should have done the job?)
'hideuser' fixed in r49222. So you can manually hide the log item, but the corresponding RC row is still visible?
(In reply to comment #6) > 'hideuser' fixed in r49222. > > So you can manually hide the log item, but the corresponding RC row is still > visible? > Yeah, exactly. Even stranger, is the log entry on Special:Log or Special:Log/block is hidden properly.
Can you give me the logid (&logid=x) ?
Did you try unhiding and hiding it again?
(In reply to comment #8) > Can you give me the logid (&logid=x) ? > URL field has: http://ko.wikipedia.org/w/index.php?title=%ED%8A%B9%EC%88%98%EA%B8%B0%EB%8A%A5:%ED%8A%B9%EC%A0%95%ED%8C%90%EC%82%AD%EC%A0%9C&target=%ED%8A%B9%EC%88%98%EA%B8%B0%EB%8A%A5%3A%EA%B8%B0%EB%A1%9D%2Fblock&logid[]=166265 so logid is 166265 (kowiki)
Hmm, the key and timestamp (used for index) match as they should. Not sure what the issue is... mysql> SELECT rc_logid,rc_timestamp FROM recentchanges WHERE rc_user_text = 'Kys951' AND rc_log_type = 'block' AND rc_title LIKE 'EV%'; +----------+----------------+ | rc_logid | rc_timestamp | +----------+----------------+ | 166263 | 20090405042100 | | 166264 | 20090405042117 | | 166265 | 20090405042154 | +----------+----------------+ 3 rows in set (0.01 sec) mysql> SELECT log_id,log_timestamp FROM logging WHERE log_id IN(166263,166264,166265); +--------+----------------+ | log_id | log_timestamp | +--------+----------------+ | 166263 | 20090405042100 | | 166264 | 20090405042117 | | 166265 | 20090405042154 | +--------+----------------+ 3 rows in set (0.01 sec)
(In reply to comment #9) > Did you try unhiding and hiding it again? > I can't tell if that was tried (was another steward doing it) from the logs since they describe what was done in Korean (why?!)... but I just tried that and it worked. Of course it shouldn't be necessary to do that... :\
Fixed in r49222. I think the issue starting with hideuser. It didn't set rc_deleted, and revisiondelete doesn't do anything if log_deleted isn't changed.
