Special page to list deleted contributions of a user
Closed, ResolvedPublic

Description

Author: gonia

Description:
To decide if some user or IP should be blocked one should know the previous
behaviour. As the deleted articles do not show in user's contribution list, it
is difficult to see if that person is a persistent vandal or just learns what
they can do. Many vandals tend to create articles that get deleted soon. If
there was an option to list contributions to deleted articles it would make
things easier.


Version: unspecified
Severity: enhancement

Details

Reference
bz1699
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz1699.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 15 2005, 3:03 PM

mrnobo1024 wrote:

*** Bug 1713 has been marked as a duplicate of this bug. ***

zigger wrote:

*** Bug 2639 has been marked as a duplicate of this bug. ***

zigger wrote:

Bug 1713 and bug 2639 requested that only sysops be able to see the deletions.

Bug 881 requested that deletions also be shown in watchlists.

brion added a comment.Mar 13 2006, 2:06 AM

Removed bogus dependency.

This bug is dependent on reworking the page deletion system to be based off of revision
deletion flags.

Wiki.Melancholie wrote:

But when a non-sysop or an IP wants to have a look on the
previous, deleted edits of a suspicious user (Special:
Contributions/...) the bug 5237 has to be resolved before, or am I
wrong? Unless you want to restrict this bug to sysops, the
dependency wasn't "bogus", I would say.

brion added a comment.Mar 13 2006, 2:20 AM

No, these are separate issues.

aaron added a comment.Nov 16 2006, 3:58 PM

I wrote a DeletedContribs viewer here:
http://www.mediawiki.org/wiki/DeletedContributions

However, two things must be pointed out:
*This requires the relavent SQL query for indexing. I don't know how expensive
that is.
*The current archiver (Article.php) skips rev_deleted, so "apply these
restrictions to Sysops" is lost when the page is archived, so it just shows as
normal here. This extension does check for ar_deleted, but it is not stored at
mw_hidden currently

aaron added a comment.Nov 16 2006, 4:01 PM

A specialpage extension for Sysops

attachment SpecialDeletedContributions.php ignored as obsolete

I just independently wrote and committed a special page for browsing deleted
contributions (r17968). At a quick glance, it seems to be fairly similar the
VoA's patch. (Great minds think alike... :-)

robchur wrote:

With appropriate indexes on the archive table, perhaps we could evaluate the
performance cost of a UNION (which would allow us to integrate the lists in some
wonderful form) against separate pages...

...then again, separate pages do offer a nice, simple, end-user friendly way of
separating the information.

robchur wrote:

*** Bug 8686 has been marked as a duplicate of this bug. ***

aaron added a comment.May 14 2007, 9:54 PM

*** Bug 8017 has been marked as a duplicate of this bug. ***

aaron added a comment.May 14 2007, 9:54 PM

*** Bug 9914 has been marked as a duplicate of this bug. ***

My implementation of Special:DeletedContributions, together with a
QueryPage-based rewrite of Special:Contributions and a branched-out
Special:NewbieContributions is at
[http://svn.wikimedia.org/viewvc/mediawiki/branches/vyznev/].

The reason it's not in the trunk is that the QueryPage-based paging turned out
to be too inefficient, and I lack the familiarity with MySQL needed to optimize
it properly. Losing the inheritance from QueryPage would also necessarily move
all sorts of ugly low-level detail back into the Special:Contributions code,
unless perhaps some kind of a more efficient replacement was written for
QueryPage first.

If you think you can do something with it, feel free to pick it up from where I
dropped it.

Using cu_changes to get recent deleted edits (3 months old) is the only viable
solution.

cuc_this_oldid not having a corresponding rev_id when joined on revision should
signify a deleted edit. These could be listed (timestamp links do undelete could
be used perhaps).

guy.chapman wrote:

Not to let the best be the enemy of the good, simply returning a list of the
deleted articles to which the user contributed at some point would be a huge
step forward, it certainly does not need to be integrated with contribution
history to be seriously useful.

titoxd.wikimedia wrote:

(In reply to comment #16)

Not to let the best be the enemy of the good, simply returning a list of the
deleted articles to which the user contributed at some point would be a huge
step forward, it certainly does not need to be integrated with contribution
history to be seriously useful.

Actually, that would be essentially the same query.

What is needed is an index that associates ar_user_text and perhaps
ar_timestamp, or if we are going to go for pages as well, ar_user_text and
ar_namespace/ar_title.

ayg wrote:

*** Bug 10122 has been marked as a duplicate of this bug. ***

aaron added a comment.Jun 14 2007, 2:45 AM

*** Bug 10251 has been marked as a duplicate of this bug. ***

Slakr added a comment.Jun 22 2007, 4:03 AM

Wouldn't it just be easier to look on the bright side of things and instead of listing deleted contribs, list all page creates? That way we can add it to logging without worrying about all this index nonsense and just let all page creations be logged outright, so that when deleted page creations are listed, they're simply shown as redlinks.

mets501wiki wrote:

What if a page is created, deleted, and then created by another user.
Who gets credit for the "create"?

guy.chapman wrote:

I don't think create-only will work. If an account is tag-teaming with socks, or making large numbers of biased edits to a stub which then gets deleted as a result, it won't show up.

aaron added a comment.Jun 23 2007, 2:48 PM

Committed to SVN as "DeletedContributions" in /extensions.

aaron added a comment.Jun 23 2007, 6:01 PM

See r23295.

gangleri wrote:

*** Bug 10492 has been marked as a duplicate of this bug. ***

gangleri wrote:

*** Bug 10525 has been marked as a duplicate of this bug. ***