This seems to be intended - imagine someone would report an user to enwiki OSes, they'd say "no, this can be public" and only blocked it normally, and then stewards would independently suppress the user, effectively overruling enwiki's decision.

In T25310#6472279, @Urbanecm wrote:

This would be quite easy to do once T189073 is done (hopefully, soon).

T189073: Refactor logic for creating and logging a block out of SpecialBlock so it can be easily reused elsewhere has been done for a while - any updates?

In T25310#6693716, @DannyS712 wrote:

In T25310#6472279, @Urbanecm wrote:

This would be quite easy to do once T189073 is done (hopefully, soon).

T189073: Refactor logic for creating and logging a block out of SpecialBlock so it can be easily reused elsewhere has been done for a while - any updates?

T270558: Make it possible to inject IDatabase into BlockUser and T270559: DatabaseBlockStore::updateBlock should accept IDatabase as a parameter are the new blockers, both are pending a patch.

Some new workflows (e.g. such as those related to the https://www.mediawiki.org/wiki/Talk_pages_project) may be running in to this as well - as their tools in development attempt to auto-complete usernames locally, and will pull in locally blocked but not hidden usernames that were already globally hidden - requiring local oversighter-admins to go back and reblock globally hidden usernames to get these out of the autocomplete seems like a bad workflow.

See also T277919 where the issue regarding username autocompletion was initially raised. With such tools very significantly raising the visibility of username lists, making sure they don't display ones that are potentially libellous (e.g. accusations of paedophilia) or contain non-public information (e.g. other editor's home addresses) is now a much higher priority.

cross-posting from gerrit:

how urgent is this?

I can see @Urbanecm proposes passing IDatabase around even more, but that's just going to prolong the suffering - it's a proliferation of the same pattern used for block insertion, and mixing a store pattern with passing along the database never really work to a full extent. A proper solution is not to pass along the database from the very top of the stack, but use patterns already in place for cross-wiki services:

1. DatabaseBlock needs to become a WikiAwareEntity. Same with BlockRestriction. It's now possible since UserIdentity is cross-wiki aware.
2. DatabaseBlockStore needs to become a proper cross-wiki store, with a DatabaseBlockStoreFactory like ActorStoreFactory or RevisionStoreFactory. Same with restriction store (fun fact, right now if you try to insert cross-wiki block with restrictions, it will insert restrictions to the local wiki and block to the other wiki)
3. block commands need to have $wikiId parameter, get injected a DatabaseBlockStoreFactory and fetch the correct store.
4. The entire system needs to get more validation added regarding correct wiki.

If you're interested in tackling this, PET can help out as a part of expedition project. We will probably do it ourselves, but it will not likely be on the very top of our agenda.

@Pchelolo This task is not very important IMO. If passing IDatabase is not how it should be done, and the proper mechanism is not yet available, I believe it can wait. We have a script which can be used in cases this behavior is really necessary for some reason :).

The sister task, T281972, is much more important :).

In T25310#6987485, @Xaosflux wrote:

Some new workflows (e.g. such as those related to the https://www.mediawiki.org/wiki/Talk_pages_project) may be running in to this as well - as their tools in development attempt to auto-complete usernames locally, and will pull in locally blocked but not hidden usernames that were already globally hidden - requiring local oversighter-admins to go back and reblock globally hidden usernames to get these out of the autocomplete seems like a bad workflow.

Well, this came up in practice now, see T294713. Someone has registered offensive usernames for every letter of the alphabet, all of them are locked and hidden globally but also blocked and not hidden on English Wikipedia, and now they are appearing on top of autocomplete results in the reply tool.

We're mitigating this by filtering out all indefinitely blocked users from the reply tool autocompletion (T294783), but that feels like an inappropriate solution for me – it shouldn't be our decision to make whether they're shown or not. But we have no way to respect the decisions of oversighters right now due to this bug.

In T25310#6472278, @Urbanecm wrote:

This seems to be intended - imagine someone would report an user to enwiki OSes, they'd say "no, this can be public" and only blocked it normally, and then stewards would independently suppress the user, effectively overruling enwiki's decision.

While I get your point, I don't really think this represents reality. Most sysops are no OSes and thus did not made this decision. This especially applies for small wiki where there are no local OSes.

In T25310#6704233, @Urbanecm wrote:

In T25310#6693716, @DannyS712 wrote:

In T25310#6472279, @Urbanecm wrote:

This would be quite easy to do once T189073 is done (hopefully, soon).

T189073: Refactor logic for creating and logging a block out of SpecialBlock so it can be easily reused elsewhere has been done for a while - any updates?

T270558: Make it possible to inject IDatabase into BlockUser and T270559: DatabaseBlockStore::updateBlock should accept IDatabase as a parameter are the new blockers, both are pending a patch.

Could you briefly explain what your plan for fixing this is/was?

Note on prioritization
I'm removing this task as blocking the deployment of the Reply Tool as an opt-out feature on desktop at en.wiki now that the Editing Team has resolved three issues which, we think, will significantly lower the risk of abusive usernames appearing within the Reply and New Discussion Tools's username suggestion list:

• {T294713}
• T294783: Exclude permanently blocked users from DiscussionTools' username suggestion list API results
• T294774: Constrain DT's username suggestion list results to people who have edited before

@Urbanecm: Isn't it the easiest and fastest way to change the wiki software like:

1. Fully delete the harmful user name from all wiki databases when it's suppressed.
2. Blacklist the harmful user name in a restricted file to globally avoid a recreation of a user account having the same account name.

OR

1. Delete the suppressed harmful user name from the database tables actor and user
2. and put it into a restricted WMF database table for usage as blacklisting to globally avoid a recreation of a user account having the same account name.

global suppressions are currently revertible in their design, not only because those are sometimes placed incorrectly. Your proposed changes would break that and I'm not sure if that would be a good thing.

Agreed; if a name is so bad it needs to be wiped entirely from the system, the WMF should be doing that themselves.

Who of WMF I have to contact to wipe those user names entirely? In dewiki it's unfortunately not very rarely, to suppress such harmful user names.

But otherwise the software isn't doing what I expect. If I suppress a user name locally then I expect, that the user name can't be reading publicly locally by any users any more. That's the result of a suppression and should work. And some years ago, I don't have the exact date, it worked properly. We have a big bunch of suppressed user names from some years ago that cannot be read publicly.

In T25310#9449914, @doctaxon wrote:

If I suppress a user name locally then I expect, that the user name can't be reading publicly locally by any users any more. That's the result of a suppression and should work.

That is how it should work, locally, and as far as I am aware still works. If the username has been locally suppressed, it doesn't really matter what global tools do because (as you say) they are suppressed on the local wiki already.

The issue is if an admin blocks a problematic name (just as a normal block), and then the name is globally suppressed, the local block and log will still show the username.

In T25310#9449889, @doctaxon wrote:

Who of WMF I have to contact to wipe those user names entirely? In dewiki it's unfortunately not very rarely, to suppress such harmful user names.

You can contact the Trust and Safety team at ca@wikimedia.org. (As far as I know they use the same tools that community members have access to, but they can help you figure out the problem if something is not working as expected.)

In T25310#9449947, @Primefac wrote:

The issue is if an admin blocks a problematic name (just as a normal block), and then the name is globally suppressed, the local block and log will still show the username.

Yes, exactly.

There is actually a WMF team currently working on changes to blocks that will likely fix this bug as well – see T194697 and https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multiblocks for status updates.

In T25310#9450067, @matmarex wrote:

There is actually a WMF team currently working on changes to blocks that will likely fix this bug as well – see T194697 and https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multiblocks for status updates.

Yes, if I'm understanding correctly this issue would be resolved by T194697: Multiblocks — Allow for multiple, simultaneous blocks with different expiration dates. as doLocalSuppression will not fail once $wgEnableMultiBlocks is set to true.

https://de.wikipedia.org/wiki/Spezial:Benutzer?username=Horst+Gr%C3%A4bner+Fucker&group=&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=50

This user name is for dewiki blocked and suppressed, but the line in Special:Users is not crossed out. When you have suppress user rights (oversight) then you can read the line crossed out. Here the line is not crossed out. What is wrong? What did I understand wrong?

It is blocked but not suppressed locally at dewiki – the block is public here: https://de.wikipedia.org/wiki/Spezial:Liste_der_Sperren?wpTarget=%231090305

It is also blocked and suppressed globally, and some parts of the code can handle this situation (so it shows as crossed-out in some places), but not all.