Exists. Not enabled on Wikimedia projects (the suppress right is disabled).

jeluf wrote:

Please find community consensus before filing config change requests.

cometstyles wrote:

A community discussion is taking place on Meta and the consensus is clear (http://meta.wikimedia.org/wiki/Metapub#Globally_hidden_usernames_should_be_hidden_locally_too.2C_and_local_hiding_of_usernames_should_be_possible )

Hiding accounts, especially ones that have contributions, is deceptive and unnecessary. If there's an issue with the account names, they shouldn't simply be swept under the rug, they should be dealt with -- permanently. Recommend WONTFIX.

WJBscribe wrote:

It might be better if you argued your point in the discussion on meta about whether this feature should be enabled rather than here - prior to your comment, no objections had been voiced. What is it you propose should be done to deal with the matter instead?

Do note that some wiki can't rename users to deal with abusive usernames. Namely wikia or anyone else using the shared user database will find it nearly impossible to rename users.

Though, also note that hiding of bad usernames is something that can be created completely as an extension. That's one of the possible uses of the hooks to Special:ListUsers added awhile back.

cometstyles wrote:

Ok the poll has 45 supports and 2 opposes (96% support for the idea), I would call that a majority so I hope a developer can look into this as soon as possible..

spacebirdy wrote:

That vote is now to be found in the archive still btw.

http://meta.wikimedia.org/wiki/Wikimedia_Forum/Archives/2008-08#Globally_hidden_usernames_should_be_hidden_locally_too.2C_and_local_hiding_of_usernames_should_be_possible

Can now be done by oversighters.

lar wrote:

Thanks for the fix. I suggest that perhaps that is too restrictive, and that perhaps admins (or 'crats?) should have the ability. Or alternatively that it be one of the things assignable in global groups so it could be tweaked?

Well, sysops will be able to do that when rev deletion will be enabled for them, isn't it?

Regards
DerHexer

spacebirdy wrote:

This is not a fix, the hiding of global accounts from the global _and_ local userlist was requested because it is a real unecessary workload to rename all the names on each wiki in case of offensive or personal-information-leaking accountnames.

Best regards

mike.lifeguard+bugs wrote:

(In reply to comment #12)

This is not a fix, the hiding of global accounts from the global _and_ local
userlist was requested because it is a real unecessary workload to rename all
the names on each wiki in case of offensive or personal-information-leaking
accountnames.

Best regards

Indeed, globally hiding the username should do so locally as well. Otherwise, one is required to hide the username on many many wikis. Whether this uses the revision deletion log suppression or something else is for a coder to decide, though I think it makes sense to use pre-existing infrastructure. Since stewards have access to oversight/revision deletion it seems to me that using log suppression for this would be uncontroversial, even though it'd affect all wikis.

mike.lifeguard+bugs wrote:

As well, log suppression hides the username only in the log, not in Special:ListUsers, which is wanted here.

mike.lifeguard+bugs wrote:

(In reply to comment #14)

As well, log suppression hides the username only in the log, not in
Special:ListUsers, which is wanted here.

There is now the block option "Hide username from the block log, active block list and user list" which has bug 17831. Ideally, a block of that sort would be triggered for every local account when the global account is locked and hidden, since currently this must be done for each wiki manually. As well, AFAIK, only stewards can access this option currently.

mike.lifeguard+bugs wrote:

*** Bug 18182 has been marked as a duplicate of this bug. ***

mike.lifeguard+bugs wrote:

Hopefully a clearer summary -- when an account is hidden it should be hidden. Blocks using wpHideName (which probably has a name other than the id?) do that, and stewards already have access to that. One should hook onto the other - when an account is hidden w/ CentralAuth, it should block using wpHideName locally for every unified account.

(In reply to comment #17)

Hopefully a clearer summary -- when an account is hidden it should be hidden.
Blocks using wpHideName (which probably has a name other than the id?) do that,
and stewards already have access to that. One should hook onto the other - when
an account is hidden w/ CentralAuth, it should block using wpHideName locally
for every unified account.

That's a terrible implementation, we'd have to come up with something better than that.

mike.lifeguard+bugs wrote:

(In reply to comment #18)

That's a terrible implementation, we'd have to come up with something better
than that.

That's what we're doing (semi-)manually. Do you know what a better implementation might be?

mike.lifeguard+bugs wrote:

AFAIK, vvv's recent work on CentralAuth fixes this. Adding him to CC to check if that's the case.

(In reply to comment #20)

AFAIK, vvv's recent work on CentralAuth fixes this. Adding him to CC to check
if that's the case.

It does but does not add local log entries which I'd endorse.

Remove shell keyword, nothing for them to do

For convenience: I think bug 23310 may be related to this one.

(In reply to comment #21)

It does but does not add local log entries which I'd endorse.

It does. I believe if we need log entries, that would need another bug, not this.