Last modified: 2011-01-25 01:36:19 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 4150 - Record "new" pages on User contributions
Record "new" pages on User contributions
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 30 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 4406 6847 7077 (view as bug list)
Depends on:
Blocks: 5469
  Show dependency treegraph
 
Reported: 2005-12-03 01:25 UTC by Catherine Munro
Modified: 2011-01-25 01:36 UTC (History)
6 users (show)

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


Attachments
patch for r16149 SpecialContributions.php to show page creations (2.15 KB, patch)
2006-08-21 04:31 UTC, Dan Li
Details

Description Catherine Munro 2005-12-03 01:25:30 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.
Comment 1 Brion Vibber 2005-12-03 01:27:30 UTC
Newness isn't currently tracked in the revision table.
Comment 2 Kyle Barbour 2005-12-28 21:53:07 UTC
*** Bug 4406 has been marked as a duplicate of this bug. ***
Comment 3 Marco 2006-01-02 13:19:43 UTC
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.
Comment 4 Rob Church 2006-01-02 13:21:10 UTC
That would be one bloody nasty query. I pity the bugger who writes that.
Comment 5 Ævar Arnfjörð Bjarmason 2006-01-13 20:58:59 UTC
*** Bug 4597 has been marked as a duplicate of this bug. ***
Comment 6 Rick DeNatale 2006-01-13 22:57:59 UTC
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.
Comment 7 Filip Maljkovic [Dungodung] 2006-07-28 22:33:34 UTC
*** Bug 6847 has been marked as a duplicate of this bug. ***
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-20 17:20:26 UTC
*** Bug 7077 has been marked as a duplicate of this bug. ***
Comment 9 Dan Li 2006-08-21 04:31:02 UTC
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.
Comment 10 Rob Church 2007-04-11 02:38:29 UTC
*** Bug 9555 has been marked as a duplicate of this bug. ***
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-08-27 03:57:37 UTC
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 . . .
Comment 12 Aaron Schulz 2008-04-06 16:03:58 UTC
(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.
Comment 13 Aaron Schulz 2008-04-06 16:08:20 UTC
Actually, why not start with RC and join on revision?
Comment 14 Brion Vibber 2008-04-07 20:41:31 UTC
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. :(
Comment 15 Aaron Schulz 2008-04-07 22:40:36 UTC
(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 ;)

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


Navigation
Links