Proposed patch has been prepared, but has to wait for the maintenance script in CentralAuth to be merged and then rolled out to all wikis (actually, just to Meta-Wiki would be sufficient).

Given that Wikitech is now part of SUL, should this be considered resolved?

As of now, the recovery codes are generated using Base32, which uses capital letters and numbers 2-7. Should the task be considered resolved then?

In T418484#11871719, @.nhals8 wrote:

(Relay from viwiki)

Is this an immediate and required change for wikis with the above settings?

Let's keep in in QA for a moment, to ensure that there are no side effects (shouldn't be any).

Closing this as resolved – as part of the current work on 2FA enforcement from local and global groups, a broader list of 26 groups to require 2FA from was published on: https://meta.wikimedia.org/wiki/Mandatory_two-factor_authentication_for_users_with_some_extended_rights

Done in T421851 and T421852

In T424935#11878480, @matmarex wrote:

From reading the docs, bumping the cache version should not cause this problem (although I didn't test it, but we bumped the version at least 13 times before and did not notice problems like this), but changing the cache key probably did.

During the day, I've been looking at https://pl.wikipedia.org/wiki/Specjalna:Wkład/M_Z_Wojalski?uselng=en – user who's been locked today UTC morning. Throughout the day, the page didn't display a notice about the account being locked (only global block was shown). Only a while ago I noticed that the lock notice is there.

Should be fixed now

In T418484#11865229, @lettherebedarklight wrote:

does this change apply to the extended-confirmed right?

I have added the following text to the next Tech News issue:

There is a new change in how new users are autoconfirmed that will improve anti-vandalism protection. Currently, users who have had an account for a few days and made a few edits are automatically added to the Autoconfirmed users group. This configuration tends to be exploited by some vandals, who create accounts and start to use them only after some time. To mitigate this, the configuration will be updated next week so that – for the purpose of becoming autoconfirmed – the account age will be counted from their first edit, instead of registration date. The numeric value of the age threshold will remain the same. This change will be deployed only to wikis which require at least one edit as part of the autoconfirmation conditions.

In T422656#11808985, @Ladsgroup wrote:

So I looked into this. Adding the column is one aspect, you definitely need to add an index for it too. For the index, since you're not looking for similar results or ordering, maybe you can use hash indexes to improve lookup and reduce space.

Thanks for the analysis and sorry for responding late here

In T422656#11814746, @Bugreporter wrote:

make sure any query that looks up based on gu_email, use the normalized version instead.

It will be awkward if we change how "normalized version" is defined in the future

In T418484#11666824, @mszwarc wrote:

What if we applied caching in the code looking for first edit timestamp

I've backfilled interwiki rights logs on all wikis