Last modified: 2011-08-14 20:36:12 UTC
Hello, es.wikipedia has achieved consensus on the following change for the new pages special page: users with the right patroller can mark new pages as patrolled so that they are not shown in yellow anymore in the special page. New pages marked for deletion are not marked as patrolled but, since it takes a while unter one admin deletes them, those pages are reviewed by many users again and again. To cope with this problem we request the following enhancement of the interface: if a page is marked with a certain template (in es.wp it would be {{destruir|reason}}) or if the page is listed in a certain category (in es.wp it would be [[Categoría:Wikipedia:Borrar (definitivo)]]), the page should be shown in the special page red, in similar way as the unpatrolled pages are shown yellow. With his feature we would save lots of resources and easy patrollers and admins to focus on the pages they can help with. Thanks in advance and best regards from es.wp. User Poco a poco References: http://es.wikipedia.org/w/index.php?title=Wikipedia:Caf%C3%A9/Portal/Archivo/Propuestas/Actual&oldid=48411392#Re-revisar_p.C3.A1ginas_nuevas
We could probably do this with a category, and create a separate CSS class for pages in a specific category. That would require a query against categorylinks for each page in Special:Newpages and a new CSS class like li.not-patrolled.
Created attachment 8851 [details] A patch to allow a pages that are members of a specified category to be highlighted differently on Special:Newpages.
Created attachment 8852 [details] Updated: A patch to allow a pages that are members of a specified category to be highlighted differently on Special:Newpages. This corrects some inappropriate quoting syntax in the query, and moves the addition of the categorylinks table to the conditional where it belongs.
I don't think this is something we should put into core. It seems like this could easily be done with some JS if the information is exposed via the API, though.
I really think that this features could be used by everybody, but anyhow, who can help us to get this in JS implemented? Thanks.
Anyone familiar with JavaScript and jQuery should be able to do this: * Fetch the page names from the page * Make a request to the API for those titles with the categorymembers querymodule * If the returned object contains a certain category store it in an array * Create a CSS selector fed to jQuery for all these page names and call addClass()
how about fixing the actual issue, namely, that patrolling only allows for "unpatrolled" and "patrolled" states. What you want is a third state, basically "found to be bad". So, how hard would it be to add support for more than two states to the patrolling feature?
(In reply to comment #7) > how about fixing the actual issue, namely, that patrolling only allows for > "unpatrolled" and "patrolled" states. What you want is a third state, basically > "found to be bad". So, how hard would it be to add support for more than two > states to the patrolling feature? It wouldn't be too complicated, but it seems to be out of scope for the patrolling feature. Mainly because patrolling is for revisions, not pages. Assuming the latest revision for the entire page may be okay for the FlaggedRevs extension but not for core patrolling. This sounds like a great feature request for FlaggedRevs, or perhaps FlaggedPages. Another long-time proposal that seems to overlap with this a little bit is the "Special rights requests queue" extension. An extension where users can make request for certain actions to be taken that they do not want or are unauthorized to perform (page moves, user blocks, user right changes, deletions etc.) Such an extension could then hook into patrolling of core, FlaggedRevs or both to filter out ones that have pending requests for a certain action (eg. delete). The obvious conclusion is though that neither templates, categories or long pure-wikitext pages are a long-term solution to deletion requests, page moves and the like (as also concluded by Jimmy Wales' talk at Wikimania 2011).
The latter part was mentioned from time to time, but never on bugzilla afaik. Logged under bug 30373.
