Last modified: 2011-01-25 01:36:19 UTC
[[Special:Contributions]] records minor (m) and most recent (top) contributions. Would it be possible to list New (N) articles there -- articles which the user created -- as on the Recent Changes page? As a secondary idea, it would also be nice to be able to filter the Contributions list to show all articles which the user created. Just a nice-to-have for users reviewing their own contributions, but can also be useful for tracking page-creation vandals.
Newness isn't currently tracked in the revision table.
*** Bug 4406 has been marked as a duplicate of this bug. ***
That would be a nice job to do, but most nicest would be when it is possible to make a whole page out of the data.
That would be one bloody nasty query. I pity the bugger who writes that.
*** Bug 4597 has been marked as a duplicate of this bug. ***
Bug 4597 is NOT a duplicate, it is asking for a way to filter Special:Contributions to only show contributions which are the latest editions of an article. THIS bug is asking for something different, it asks for NEW articles (i.e. created by the contributor) to be distinguished.
*** Bug 6847 has been marked as a duplicate of this bug. ***
*** Bug 7077 has been marked as a duplicate of this bug. ***
Created attachment 2261 [details] patch for r16149 SpecialContributions.php to show page creations Attached patch gets information about page creations from recent changes, so only recently created pages will get an "N" next to them. I'm hoping this will be enough for dealing with vandalism. Finding all page creations, even if they have been deleted from recent changes, would either require tracking "newness", which, as Brion points out, isn't done yet, or it would require a relatively expensive (I think?) GROUP BY query.
*** Bug 9555 has been marked as a duplicate of this bug. ***
The patch is outdated and can't be applied as-is, since SpecialContributions has been rewritten since it was created. Also, the modification to the query is unacceptable: it joins each revision to *every* row corresponding to it in recentchanges, causing many extra rows to be returned. That makes even the recentchanges solution somewhat nontrivial, or at least no way of avoiding that efficiently comes immediately to mind. There probably is some way, but I can't think of it . . .
(In reply to comment #11) > The patch is outdated and can't be applied as-is, since SpecialContributions > has been rewritten since it was created. Also, the modification to the query > is unacceptable: it joins each revision to *every* row corresponding to it in > recentchanges, causing many extra rows to be returned. That makes even the > recentchanges solution somewhat nontrivial, or at least no way of avoiding that > efficiently comes immediately to mind. There probably is some way, but I can't > think of it . . . > Hmm, isn't there a user_text, timestamp index for recentchanges? Perhaps that can be to limit the row scanning needed for the join. Then the rc_this_oldid and rc_type condition can be checked on like 1-2 rows.
Actually, why not start with RC and join on revision?
Joining to recentchanges is going to limit you to activity within the $wgRCmaxage limit. If you want this to be more generally useful, it's probably necessary to extend the fields in the revision table. In theory you could just check for empty rev_parent_id, but this field is still unused afaik. :(
(In reply to comment #14) > Joining to recentchanges is going to limit you to activity within the > $wgRCmaxage limit. If you want this to be more generally useful, it's probably > necessary to extend the fields in the revision table. > > In theory you could just check for empty rev_parent_id, but this field is still > unused afaik. :( > A few changes to the Revision code, and it can be populated. I may whip up a maintenance script if someone cares (which would assume first=new). I thought about doing this before but always thought roman would come back and finish...didn't happen ;)
