Last modified: 2008-02-08 00:35:11 UTC
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
*** Bug 1713 has been marked as a duplicate of this bug. ***
*** Bug 2639 has been marked as a duplicate of this bug. ***
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.
Removed bogus dependency.
This bug is dependent on reworking the page deletion system to be based off of revision
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.
No, these are separate issues.
I wrote a DeletedContribs viewer here:
However, two things must be pointed out:
*This requires the relavent SQL query for indexing. I don't know how expensive
*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
Created attachment 2714 [details]
A specialpage extension for Sysops
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... :-)
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.
*** Bug 8686 has been marked as a duplicate of this bug. ***
*** Bug 8017 has been marked as a duplicate of this bug. ***
*** 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
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
If you think you can do something with it, feel free to pick it up from where I
Using cu_changes to get recent deleted edits (3 months old) is the only viable
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).
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.
(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
*** Bug 10122 has been marked as a duplicate of this bug. ***
*** Bug 10251 has been marked as a duplicate of this bug. ***
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.
What if a page is created, deleted, and then created by another user.
Who gets credit for the "create"?
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.
Committed to SVN as "DeletedContributions" in /extensions.
*** Bug 10492 has been marked as a duplicate of this bug. ***
*** Bug 10525 has been marked as a duplicate of this bug. ***