A potential complication that occurred to me this morning - pages are always watched in pairs, the page and their talk page, and it's impossible to know which of the two (or both) a user was interested in watching. Should the criteria the tool can define be checked against both the page and its talk page?

T378138 is the only other task I could find that might be related to this?

In T387443#10588594, @Johannnes89 wrote:

perhaps linking the notification to https://www.mediawiki.org/wiki/Extension:AbuseFilter#Emergency_throttling would be helpful? Essentially only actions like "block", "blockautopromote" or "degroup" will be disabled when a filter is throttled, warn and disallow (the most common actions) will still work as usual.

I've just spotted that I got the following email too, which leaves me even more confused - was it throttled or not?

Possibly the cause of T379476?

Screen recording demo: https://drive.google.com/file/d/1r1euuXmRVD3iG-dWbI_iRwcZgWuslMk8/view?usp=sharing

You can install and try the user script by adding the following line to your https://en.wikipedia.org/wiki/Special:MyPage/common.js file:

https://github.com/WikipediaLibrary/TWLight/pull/1337

A couple of notes I made while going through this that I forgot to post until now. They can be followup tasks or I could wrap any necessary work into this PR:

• Do we still need authorization_backfill.py? I think this was a one-time script.
• There's a TODO in user_check.py - is there a Phab task for this or shall I file one?

In T353868#9792217, @Pigsonthewing wrote:

I still get the same error as in my original report

https://github.com/WikipediaLibrary/TWLight/pull/1293

https://github.com/WikipediaLibrary/TWLight/pull/1292

https://github.com/WikipediaLibrary/TWLight/pull/1288

As far as I can gather, Django admin by default is only capable of searching admin on fields in the database - searching on a custom defined field is not supported out of the box.

In T356119#9496535, @Harej wrote:

@Samwalton9 How is the state of UnlinkedWikibase these days? If our goal is to support Wikipedia Lua modules that use Wikidata, and to enable the language dropdown, how much work would it take?

In T299510#9342383, @Scardenasmolinar wrote:

PR for alternative approach: https://github.com/WikipediaLibrary/TWLight/pull/1224

Thanks @KCVelaga_WMF! Some things I'm noticing initially:

• It looks like is_self_revert is actually finding whether the edit was later reverted by the same editor, not whether the edit itself is a revert of a previous edit by this user. We're looking for the latter.
• newcomer tasks: We're specifically interested in the newcomer task links tag but this dataset seems to be targeting newcomer tasks in general - there are other newcomer tasks (like copyediting) which we want to take action on, but we think 'add a link' is so unambiguous that we should always leave that one alone.
• It looks like there are zero page creations in the datasets - is that just because page creations are rarer, or are they inherently excluded because the Revert Risk API can only consider edits which have a parent revision (or something else)?

https://github.com/WikipediaLibrary/TWLight/pull/1210

Seems like the failing test was unrelated to this PR.

WIP PR at https://github.com/WikipediaLibrary/TWLight/pull/1209. I'm getting a failing test but can't figure out why.

I need to start remembering to switch accounts when appropriate. This above patch was made in my volunteer capacity :)

Filed a PR with a fix for the 'overwrite with blank email' bug I noted above: https://github.com/WikipediaLibrary/TWLight/pull/1200

I did some testing on this, and the only way I could reproduce it was to log in with an account which has no email attached in Wikipedia. Then update my email address in the library while keeping the "Use my Wikipedia email address" checkbox ticked. Upon logging out of the library and back in, the entered email is blanked. If the checkbox isn't selected, this doesn't happen.

Although a nice idea, I think the current workflows are good enough, and we've moved most partners away from applications anyway, reducing the overall workload.

I boldly took the approach of adding a new config app to store this data. Awaiting feedback.

Perhaps not ideal - we should maybe be clarifying/removing the 'Satisfies Terms of Use' row too in the specific case that a block is the only disqualifying factor, but I didn't want to overcomplicate things.

I intended to make the above comments from this account :)