Last modified: 2012-10-29 16:39:58 UTC
CentralAuth allows the hiding of global accounts, would it be possible to also implement a similar feature locally? We are already seeing interwiki vandals exploiting SUL to create an account with an abusive name, make it a global account, and then visit as many wikis as possible to add entries to multiple user lists.
Exists. Not enabled on Wikimedia projects (the suppress right is disabled).
Please find community consensus before filing config change requests.
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.
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.
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..
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.
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
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
(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.
As well, log suppression hides the username only in the log, not in Special:ListUsers, which is wanted here.
(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.
*** Bug 18182 has been marked as a duplicate of this bug. ***
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.
(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?
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.
