As I was looking at this, I realized that we need to verify that our current check for blocks is actually a global check, not just checking for blocks on meta. Assuming we have/get a global block check in place, allowing overrides might turn out to be tricky. I'm imagining implementing this as a per-editor flag to not enforce the blocked status check for validity.

What happens when a user gets an additional block on a different project? Now that we have a cron job to check for recent edits, should we try to check for blocks/unblocks? That info isn't in globaluserinfo, which means we'd need to go and check userinfo for all of the user's active projects. That's actually an ideal thing to do in an async / background task like the eligibility cron job.

If we previously discovered that the oauth block check is meta only (and promptly forgot) I imagine that we left things as they were to avoid swamping the login process with a bunch of synchronous api calls.

We spoke a little about this today, reviewing in further detail on Thursday.

• There is per-project block data we can easily retrieve from somewhere, it may need to be done asynchronously with logging in. Jason is going to review docs and figure out where that data lives.
• We want to review a users' block exemption per Wiki, but without requiring us to store their block status for every Wikimedia project in our database.
• One option could be to store a hash of the block status json data and on each login, check if it changed. If so, and not in a way that means they're unblocked everywhere, make the user non-eligible again and require staff to re-review.
• We may go ahead with proxy/bundle rollout simply implementing the block check and complete staff override, with the updating/hash-check functionality coming later.

Additionally, we should make sure that users who aren't eligible due to being blocked are directed to a sensible location (the Contact form, probably) to request a review. Noted, for me, in T230524.

okay, tracked down the query for global blocks:
https://www.mediawiki.org/w/api.php?action=query&meta=globaluserinfo&guiid=<numeric_id>&format=json&guiprop=merged|unattached
It returns some really nice contextual information, such as block duration and reason. I'm going to store concatenated json of just the records that contain blocks. It's also really fast, so I think we can just let it stay synchronous after all.

PR in progress
https://github.com/WikipediaLibrary/TWLight/pull/413

estimate 25 hours of work from here

Now that we've gone through all of the bundle launch blockers, I decided to see if I could do something simpler than what I had initially planned here.
This PR should now have global block checks working (they were broken previously).
The way in which the central auth extension presents its data means that we don't even have to make an extra query after all. We're just getting back a larger response from a request we're already having to make.

Forget all of my talk about storing a json blob and hashing it. I'm going to add an "ignore blocks for bundle eligibility" property to Editors and call it a day. In the interest of quick implementation, I'd suggest that we don't build any ui for this and just leave it as a task for superusers to do in the admin site. Thoughts?

and now we've got Editor.ignore_wp_blocks to force Editor.wp_valid to true if blocks are the reason it's false.

don't build any ui for this and just leave it as a task for superusers to do in the admin site. Thoughts?

Yep, that makes sense to me.

merged into staging.