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 undeleted pages.
I'd like to echo this: it would be really nice if CheckUser searched deleted edits.
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] Summary Patch Adjust table. (Previously at bug 8290)
Created attachment 3351 [details] Table clean up
Created attachment 3414 [details] Most recent patch
Done in r21016
