Last modified: 2007-04-05 20:52:24 UTC
On MediaWiki 1.4.8, if a vandal creates one page, and that page is deleted, then
undeleted, there are no results for [[Special:CheckUser]] for that user. It
might be better if deleted pages could also store the user's IP, especially on
I'd like to echo this: it would be really nice if CheckUser searched deleted
That info isn't saved, it's gone on delete.
*** Bug 6845 has been marked as a duplicate of this bug. ***
Fixing this requires moving Checkuser to a seperate table, that acts just like
Recentchanges, but things are not removed from it one page deletion. This will
require a considerable overhaul.
An alternative to this would be to have deleted revisions kept in RC, but
somehow flagged for deletion, which would still require some serious changes.
A third option would be to add an IP field to the archive table. This is,
however, probably suboptimal; either of VoA's suggestions seems more practical.
You'd need to track IP addresses in the revision table, too.
I must strongly disagree with the suggestion to move data between tables. My
recommendation would be to add an rc_deleted field to recentchanges, and modify
SpecialRecentchanges.php, SpecialWatchlist.php, and probably a few other modules
to include a "where rc_deleted = 0" selection condition. This approach requires
a minor schema change and does not affect the efficiency of any routine
operation (new edit remains the same number of database operations with just an
extra column which is filled with a zero, deletion replaces a 'delete' with an
'update', and all other operations merely add a 'where' clause to an existing
select). The other approaches suggested above all increase the number of db
operations for either edits or deletions. The main problem is in making sure
that all access to recentchanges are properly filtered; fortunately, there do
not appear to be all that many.
Created attachment 2989 [details]
Use rc_deleted column
Revisiondelete now uses rc_deleted instead of hard-overriding the RC values,
since I might as well do that if I am adding this column and the current
revisiondelete damages CU results anyway.
However, "Apply these restrictions to sysops as well as others" still suffers
from the same pitfall as before, that is, archiving revisions (normal delete)
still effectively makes the revision Sysop viewable, even if this was checked
before. This would be true of the RecentChanges entry too. Though any Sysop
could also use (show/hide) to remove the extra restriction anyway.
The following column data is used for rc_deleted (SQL):
rc_deleted tinyint(1) unsigned NOT NULL default '0';
Created attachment 2990 [details]
rm stuff from other patch
Gah, rc_agent should'nt be in RecentChanges.php for this diff
Comment on attachment 2990 [details]
rm stuff from other patch
Scratched patch for now. Bug 8290 will change the table schema. I'll salvage
this code and make a new patch after thats done.
Created attachment 3346 [details]
(Previously at bug 8290)
Created attachment 3351 [details]
Table clean up
Created attachment 3414 [details]
Most recent patch
Done in r21016