Last modified: 2007-04-05 20:52:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3281 - Have CheckUser search deleted edits
Have CheckUser search deleted edits
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
unspecified
All All
: Normal normal with 9 votes (vote)
: ---
Assigned To: Aaron Schulz
:
: 6845 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-27 02:11 UTC by Angela
Modified: 2007-04-05 20:52 UTC (History)
2 users (show)

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


Attachments
Use rc_deleted column (24.47 KB, patch)
2006-12-30 21:56 UTC, Aaron Schulz
Details
rm stuff from other patch (19.78 KB, patch)
2006-12-30 22:03 UTC, Aaron Schulz
Details
Summary Patch (35.40 KB, patch)
2007-03-13 08:08 UTC, Aaron Schulz
Details
Table clean up (35.40 KB, patch)
2007-03-16 05:22 UTC, Aaron Schulz
Details
Most recent patch (35.40 KB, patch)
2007-04-05 01:17 UTC, Aaron Schulz
Details

Description Angela 2005-08-27 02:11:34 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.
Comment 1 Kelly Martin 2006-01-15 21:47:38 UTC
I'd like to echo this: it would be really nice if CheckUser searched deleted
edits.  
Comment 2 Brion Vibber 2006-01-15 21:53:38 UTC
That info isn't saved, it's gone on delete.
Comment 3 Aaron Schulz 2006-08-07 03:59:07 UTC
*** Bug 6845 has been marked as a duplicate of this bug. ***
Comment 4 Aaron Schulz 2006-12-02 04:34:27 UTC
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.
Comment 5 Aaron Schulz 2006-12-02 04:50:36 UTC
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.
Comment 6 Ilmari Karonen 2006-12-02 05:06:30 UTC
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.
Comment 7 Rob Church 2006-12-02 05:18:42 UTC
You'd need to track IP addresses in the revision table, too.
Comment 8 Kelly Martin 2006-12-02 06:44:47 UTC
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.
Comment 9 Aaron Schulz 2006-12-30 21:56:17 UTC
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';
Comment 10 Aaron Schulz 2006-12-30 22:03:42 UTC
Created attachment 2990 [details]
rm stuff from other patch

Gah, rc_agent should'nt be in RecentChanges.php for this diff
Comment 11 Aaron Schulz 2007-01-10 03:48:07 UTC
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.
Comment 12 Aaron Schulz 2007-03-13 08:08:50 UTC
Created attachment 3346 [details]
Summary Patch

Adjust table.

(Previously at bug 8290)
Comment 13 Aaron Schulz 2007-03-16 05:22:40 UTC
Created attachment 3351 [details]
Table clean up
Comment 14 Aaron Schulz 2007-04-05 01:17:48 UTC
Created attachment 3414 [details]
Most recent patch
Comment 15 Aaron Schulz 2007-04-05 20:52:24 UTC
Done in r21016

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


Navigation
Links