Making a 1.19 blocker since it looks like this is the result of deploying 1.19 to Meta.

Local suppression blocks works, so I assume CA is probably not inserting the local suppression blocks on all the wikis, or at least not properly.

Is it just Special:ListUsers as far as you know?

SpecialBlockList, SpecialActiveusers, ApiQueryUsers, ApiQueryBlocks, and ApiQueryAllUsers all use the same method of filtering, so should probably be double checked.

It's everywhere. I already discovered the bug. It seems to have been broken since the block refactoring in 1.17. The local user ID is new longer used in the Block constructor and it tries to get the ID for the *metawiki* user with the name.

I can see blocks for names that should be hidden in the DB, but their ipb_user field is 0, which makes all the JOINs not find them (e.g. ListUsers).

Should be fixed in r112563.

closing. reopen if it isn't.

Note that effected users will need to be reblocked.

quentinv57 wrote:

Hello. Some of the globally oversighted users are still displayed on the local user lists. I don't know if there's the same thing on some other pages, but please consider this :

https://en.wikipedia.org/w/index.php?title=Special:ListUsers&username=Sebastian Mo&group=&limit=50

Thanks by advance

(In reply to comment #9)

Hello. Some of the globally oversighted users are still displayed on the local
user lists. I don't know if there's the same thing on some other pages, but
please consider this :

https://en.wikipedia.org/w/index.php?title=Special:ListUsers&username=Sebastian Mo&group=&limit=50

Thanks by advance

Did you unblock and reblock the user? See comment #8.

quentinv57 wrote:

Hello,

I unlocked and relocked the user, it still appears in the list.

Should I unoversight and reoversight ?
If so, I'm not really comfortable with this because oversighted stuff will show up on IRC channels and logs unnecessarily.
Isn't there anyway to correct this directly from the database ? This is a technical problem, so I think it should be solved technically.

Regards,

Hi Quentinv57, I'm resolving this issue, and referring future log work to bug 34995. I think that's a manual cleanup exercise that is very different than what is described at the top of this bug.