Last modified: 2012-10-29 16:39:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14476 - Hiding a global account via CentralAuth should trigger local blocks using wpHideName
Hiding a global account via CentralAuth should trigger local blocks using wpH...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: revdel SWMT
  Show dependency treegraph
 
Reported: 2008-06-08 23:25 UTC by Will
Modified: 2012-10-29 16:39 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Will 2008-06-08 23:25:03 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.
Comment 1 Andrew Garrett 2008-06-08 23:53:48 UTC
Exists. Not enabled on Wikimedia projects (the suppress right is disabled).
Comment 2 JeLuF 2008-06-12 18:42:40 UTC
Please find community consensus before filing config change requests.
Comment 3 Cometstyles 2008-06-14 13:16:11 UTC
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 )
Comment 4 MZMcBride 2008-06-17 01:34:53 UTC
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.
Comment 5 Will 2008-06-17 02:24:57 UTC
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?
Comment 6 Daniel Friesen 2008-06-17 08:01:21 UTC
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.
Comment 7 Cometstyles 2008-06-23 23:40:40 UTC
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..
Comment 9 Andrew Garrett 2009-02-04 19:15:05 UTC
Can now be done by oversighters.
Comment 10 Larry Pieniazek 2009-02-04 20:06:56 UTC
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?
Comment 11 DerHexer 2009-02-04 20:12:03 UTC
Well, sysops will be able to do that when rev deletion will be enabled for them, isn't it?

Regards
DerHexer
Comment 12 spacebirdy 2009-02-13 07:28:31 UTC
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
Comment 13 Mike.lifeguard 2009-02-13 15:23:29 UTC
(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.
Comment 14 Mike.lifeguard 2009-02-13 15:27:33 UTC
As well, log suppression hides the username only in the log, not in Special:ListUsers, which is wanted here.
Comment 15 Mike.lifeguard 2009-03-19 19:22:00 UTC
(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.
Comment 16 Mike.lifeguard 2009-04-02 17:27:32 UTC
*** Bug 18182 has been marked as a duplicate of this bug. ***
Comment 17 Mike.lifeguard 2009-04-02 17:29:32 UTC
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.
Comment 18 Andrew Garrett 2009-07-29 14:54:52 UTC
(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.
Comment 19 Mike.lifeguard 2009-08-08 02:13:12 UTC
(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?
Comment 20 Mike.lifeguard 2010-04-26 07:32:14 UTC
AFAIK, vvv's recent work on CentralAuth fixes this. Adding him to CC to check if that's the case.
Comment 21 DerHexer 2010-04-26 13:18:59 UTC
(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.
Comment 22 Betacommand 2010-05-10 15:24:50 UTC
Remove shell keyword, nothing for them to do
Comment 23 MA 2010-07-19 19:39:47 UTC
For convenience: I think bug 23310 may be related to this one.
Comment 24 Victor Vasiliev 2011-03-22 09:03:27 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links