Pages that were previously deleted and recreated should be flagged in the New Pages Feed as likely to need immediate attention.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Tag pages that were previously deleted and add filter | mediawiki/extensions/PageTriage | master | +115 -4 |
Pages are often recreated under different but similar titles -- for example Acme Corporation, Acme (company), Acme (widgets company), etc -- to evade scrutiny. Therefore, this should be implemented by searching the archive table using both the prefix ([[Special:Undelete]] fuzzy=0) and normal search ([[Special:Undelete]] fuzzy=1) instead of just determining whether the title has deleted revisions or deletion log entries if the user is an admin. Looking for deletion log entries is fine for non-admins.
First requested 6 years ago, with the ACTRIAL now permanently rolled out last month as ACREQ, this is urgently required it is a known workaround for spammers and undeclared paid editors. Please have this included in the development work that ComTech is currently doing on the New Pages Feed.
Just noting that I use User:Writ Keeper/Scripts/deletionFinder.js to alert me to previous deletions as a workaround.
Change 508385 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/extensions/PageTriage@master] Tag pages that were previously deleted and add filter
This is ready for review, but I'm keeping the WIP flag on the patch as a reminder not to merge until we have QA resources.
Change 508385 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Tag pages that were previously deleted and add filter
@MusikAnimal Going to https://en.wikipedia.beta.wmflabs.org/wiki/Special:NewPagesFeed the feed doesn't load and I get "ReferenceError: recreated is not defined".
Full error:
ReferenceError: recreated is not defined[Learn More] load.php:3:2779 anonymous https://en.wikipedia.beta.wmflabs.org/w/load.php:3:2779 _.template/< https://en.wikipedia.beta.wmflabs.org/w/load.php:96:869 render https://en.wikipedia.beta.wmflabs.org/w/load.php:162:1956 addOne https://en.wikipedia.beta.wmflabs.org/w/load.php:182:837 forEach self-hosted:261:13 _.forEach https://en.wikipedia.beta.wmflabs.org/w/load.php:82:65 Collection.prototype[method] https://en.wikipedia.beta.wmflabs.org/w/load.php:111:673 addAll https://en.wikipedia.beta.wmflabs.org/w/load.php:183:325 trigger https://en.wikipedia.beta.wmflabs.org/w/load.php:99:681 reset https://en.wikipedia.beta.wmflabs.org/w/load.php:109:435 fetch/options.success https://en.wikipedia.beta.wmflabs.org/w/load.php:109:680 fire https://en.wikipedia.beta.wmflabs.org/w/load.php:303:897 fireWith https://en.wikipedia.beta.wmflabs.org/w/load.php:305:114 done https://en.wikipedia.beta.wmflabs.org/w/load.php:384:567 callback/< https://en.wikipedia.beta.wmflabs.org/w/load.php:387:972
My guess is you checked before update.php was ran. It appears to be loading properly now.
One other note, we didn't create a migration script to backfill data. So you may see older pages in the feed that were previously deleted but aren't marked as such. It will only take a single edit to those pages for them to get reevaluated though.
Thanks, I noticed it started working today.
After deleting a page and then creating a page with the same name, it appears in the NewPagesFeed when filtering "Previously deleted" (after a 10-15 min delay). It gets tagged "Previously deleted", which also appears in PageCuration toolbar under "Page info".
If "Page A" gets moved to "Page B" without creating a redirect (effectively deleting "Page A"), if I recreate "Page A" it will not be considered "Previously deleted". Presumably because there is no record of its deletion in the deletion log (Special:Log/delete), rather in the move logs. @joeroe If this is a concern, then a separate ticket could be raised.
@MusikAnimal I don't think we need to backfill the data.
@dom_walden That is a good catch. I suspect there might not be a real concern in that case because the page was moved and not deleted - indicating that the page was probably not harmful, which is what we are trying to catch here. Let's see if the community members raise this as a concern.
This change will be on enwiki tomorrow i.e. May 30th.
I almost left a response on Friday but decided not to because there are two really different scenarios at play here. In scenario one an article gets moved, without redirect with-in articlespace. This is as @Niharika describes. If an article is moved from mainspace to draftspace (draftify) this can mean one of several things but probably does need some thought/attention from a reviewer. In this latter scenario if the person doing the move has the page mover right they can do so without a redirect being created, which, if the article is then recreated, would merit attention from a patroller. If the person doesn't have page mover it'll end up getting deleted via R2, which I'm guessing would show up in this scenario?
@Barkeep49 If a page is moved from article space to draft space and then moved back to the article space, does it count as a "recreated" article? Does it show up in the feed as such?
Also, do you know if it is common for pages to be moved from article space to draft space?
@Niharika An article that was in article space, patrolled, moved to draft space, and then later moved back to article space, will show up in the feed as unpatrolled. And moving things from article to draft space is an incredibly common thing and there is a script (widely used among NPP and probably others) for this process: https://en.wikipedia.org/wiki/User:Evad37/MoveToDraft
Mentioned in SAL (#wikimedia-operations) [2019-05-30T21:11:08Z] <Krinkle> krinkle@mwmaint1002 Add 1 row to pagetriage_tags table on enwiki, based on PageTriageTagsPatch-recreated.sql. T224693, T189929
Mentioned in SAL (#wikimedia-operations) [2019-05-30T21:12:40Z] <Krinkle> krinkle@mwmaint1002 Add 1 row to pagetriage_tags table on testwiki db, based on PageTriageTagsPatch-recreated.sql. T224693, T189929
Mentioned in SAL (#wikimedia-operations) [2019-05-30T21:27:26Z] <Krinkle> krinkle@mwmaint1002 Add 1 row to pagetriage_tags table on test2wiki db, based on PageTriageTagsPatch-recreated.sql. T224693, T189929