kelly.lynn.martin wrote:

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.

robchur wrote:

You'd need to track IP addresses in the revision table, too.

kelly.lynn.martin wrote:

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.

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';

attachment rc_deleted.patch ignored as obsolete

rm stuff from other patch

Gah, rc_agent should'nt be in RecentChanges.php for this diff

attachment rc_deleted.patch ignored as obsolete

Comment on attachment 2990
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.

Summary Patch

Adjust table.

(Previously at bug 8290)

attachment checkuser.patch ignored as obsolete

Table clean up

attachment checkuser.patch ignored as obsolete

Most recent patch

Attached:

Done in r21016