In T229581#5417031, @DannyS712 wrote:

@MusikAnimal what about adding it to the simple counter? We include total, live, and deleted edits - it shouldn't be too hard to also have just the number of pages there

Couldn't we set the OAuth URL to Commons instead of Meta? That would ensure they an account.

We probably should create an English-only list, and move admin actions there, along with the regex for Generic rollback and Undo.

We're filtering solely on revisions, so we need to go by edit summary. You're right this assumes English. The same is true with Generic rollback, Undo, etc., which we have under global as well, though those do have tags. We probably should create an English-only list, and move admin actions there, along with the regex for Generic rollback and Undo.

Makes sense to me! I've moved it under global.

This was added by DannyS712 this past May.

This appears to already be picked up by XTools: https://xtools.wmflabs.org/autoedits-contributions/www.wikidata.org/ZI%20Jony/all?tool=HotCat

You can definitely expect more, sometimes redundant feedback with an on-wiki venue. The other advantage to using Phabricator is those who do file a bug probably know how to and will include other relevant information (such as their browser). The downside is of course that if they don't use Phabricator, they might not ever report the issue and we won't find out about it. Maybe the "Contact us" message could offer both venues? XTools has two links; "Feedback" (on-wiki forums) and "Report an issue" (Phabricator), and that seems to have worked well. Pageviews Analysis meanwhile has a "Report an issue" link that goes to the on-wiki forum, and I do get a lot of repeat questions, but it's been manageable.

In T229564#5413346, @Jony wrote:

I think It should be /* wbsetsitelink-remove:1|Site ID */ Sitelink

Wow, this is not the first time the mobile team asked about using XTools APIs! I will say the same thing as before -- while XTools typically has very good uptime (upwards of 99.9% out of the year, according to my data), it probably should not be relied upon by something like the production Wikipedia iOS app. Our APIs are more for research purposes, user scripts, other Cloud Services tools, etc., not for applications that receive significant traffic. I can guarantee however that XTools is not going anywhere, provided it's within our control :)

I've got this added, and I'll get it deployed soon.

As mentioned in T229714 we can give a way to Contact us. I am wondering what the right avenue for that would be—a talk page or a phab task or something? It would be awesome if the link would take them to a place where some stuff (like the page that caused the error) would be pre-filled.

In addition to possible concerns with the query, there are existing issues with the extension that might be exasperated. Mainly, that the query will unnecessarily be ran on every edit (which is already the case, but with a much simpler query). I think this needs to be addressed first, and whether or not that's worth our time, I'm unsure. In addition, the logic introduced with my patch feels fragile to me. I've tried to make the tests comprehensive (relative to the new code), but I can't even get them to pass, and I am not super confident the patch won't cause other unintended side effects. Finally, I suspect the community may not be pleased with some aspects of the new system. We cannot cleanly do any sort of revert detection, so if editor A changes the redirect to an article, and editor B changes back to the redirect, editor B incorrectly gets credit for the redirect itself. Flip that around and you have a worse scenario -- editor A writes an article, editor B changes it into a redirect, then editor C turns it back to the preexisting article. Now any messages you send to the creator using Page Curation will go to the wrong person :(

https://www.wikidata.org/wiki/Help:Sitelinks will work! There doesn't need to be a dedicated page for the auto-removal function.

In T229714#5409238, @Prtksxna wrote:

Thanks for all this information, @MusikAnimal 🤩
In the case of Requested data is not currently available in WikiWho database. It will be available soon., do we have any idea what soon might be (ms? hours?)? Based on that we could have a few different versions of the try again later message.

Yes, the thought is people will see it in XTools and ask "what's this?". Not critical, we can make it so that there is no link. But we still need a name. Something like "Sitelink auto-removal"?

Does not necessarily mean you got the data you need. In addition, you should look for success in the response body. This will be true if all went well. If it is false, a plain English description of the error will be provided by info.

This seems like a fitting addition, but we will need to come up with a name and something to link to for documentation. @Jony Are you aware of any internal documentation for this, say a project page on wikidata.org? I tried doing a search and couldn't find anything.

@DannyS712 Thanks for the offer! Allow me to stop you before you spend a lot of time on this, as there are some complications that we've uncovered. The primary issue is that we need to read twinkleoptions.js to find out if we should log and where. This sort of gadget dependency doesn't belong in MediaWiki. So instead we've decided to introduce a JS hook that is fired when Page Curation tags a page for speedy/proposed deletion. Then Twinkle can listen to that and perform the logging. This also means we don't need to worry about staying up-to-date with Twinkle's logic (which has changed a bit over the years). I know you contribute to Twinkle, so maybe you could help with that side of it. I'll be around to help as well, but first we need to get this hook into Page Curation. We'll be working on that soon.

Closing for now. Please reopen if I'm missing something or if the API breaks again.

I've done it the cheap way of restarting the webservice daily via cron. That'll have to do for now.

This is the new query used in my patch:

@JTannerWMF I'm assuming you didn't mean to claim/resolve this? :)

I think the proposal here is to see if the image that is tagged for deletion is being used in a template, and if so notify the template talk page. This makes a lot of sense to me. I do not think we should notify talk pages of articles that transclude the template, however, as this could amount to thousands of notifications for a single image.

I believe Geagea is talking about "Commons deletion notification bot", which edits as Community Tech bot. Notifications about new versions of files in my opinion is out-of-scope of the original wish, but I can certainly see how it would be useful.

I'm not really up to speed on what's going on, but:

Ah, see DannyS712 already identified the issue with single_tag. I saw this task via email when it was still under the old title :) Anyway, this is pretty complicated, so don't expect a quick fix.

The tag IDs come from AutoEditsRepository::getTags(), which is project-dependent. The bug seems to be due to the singe_tag option, where there are a bunch of edits with the PHP7 tag which aren't getting counted. The reasoning is to not attribute say Huggle edits as Undo or Rollback, since you'd probably only want to see native undo/rollback edits. This logic is clearly broken.

@Mujeebcpy Could you please provide a link to the endpoint you tried to use? Everything seems in working order on my end.

We've come up with a plan and I'm now resuming development.

I'm now able to reproduce this:

Login is broken for me too, in all browsers, even after clearing the browser cache and cookies. I tried restarting the webservice and clearing the server-side cache, but no luck.

Should be fixed now. Thanks for the report

Ready for QA

I was going to advise against using AbuseFilter at all. We probably shouldn't have that kind of dependency in Page Curation, especially the reliance on the implementation of a filter which we can't control (later it could get re-purposed but we still assume it's COI-related).

In T219857#5361530, @Milimetric wrote:

This can be tricky to diagnose because we don't really know what if any upstream changes are made to Hyperswitch. Do you have a more accurate idea about when you started seeing this? Is it when you made the task, beginning of April this year?

The abuse_filter_log table is apparently missing on the replicas, presumably because of this. Maybe the view definition needs to be updated?

Merged! Correct me if I'm wrong, but this is mostly about performance improvements, in particular ResourceLoader and restructuring of clientside scripting. Everything seemed in working order for me. Moving to QA to get another set of eyes.

I'm not sure that is the best idea though - per BEANS I've emailed you my concern - feel free to post it here if you think it isn't an issue

Not quite BEANS-worthy in my opinion, but thanks for the caution! I wanted to state that removing this throttling for redirects is merely technically possible. Is there anyone else hitting the rate limit? I ask because you have a bot account to get around it, no? Anyway we might be getting a little off-topic :)

In T227250#5363748, @DannyS712 wrote:

The popup window says An error occurred while marking the page as reviewed: You've exceeded your rate limit. Please wait some time and try again.
...

Okay so it sounds like there is a healthy amount of redirect patrolling using Page Curation. I suppose let's talk to the DBAs about this. If they think all those extra rows are fine, then there's no reason not to bump the expiry to 90 days, provided you're okay with the longer backlog.

The patch that changed redirects to purge after 30 days was https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/24939, which was merged by @kaldari. Perhaps he remembers the reasoning?

Waiting another week is a long time... If you tell me what to test (aside from T228677), I can help with the SWAT deploy. Or maybe @Huji could help, since they are familiar with what the patch does?