Last modified: 2008-05-30 06:33:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T13149, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11149 - Temporary block may prevent a user from winning the unified account
Temporary block may prevent a user from winning the unified account
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-01 23:48 UTC by Rotem Liss
Modified: 2008-05-30 06:33 UTC (History)
1 user (show)

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


Attachments
Patch (1.82 KB, patch)
2007-09-16 04:20 UTC, Rotem Liss
Details
Patch (4.05 KB, patch)
2007-09-18 04:25 UTC, Rotem Liss
Details
Patch (5.43 KB, patch)
2007-11-25 13:39 UTC, Rotem Liss
Details

Description Rotem Liss 2007-09-01 23:48:59 UTC
Let's say there are two users, A@awiki and A@bwiki. A@awiki has more contributions than A@bwiki, he may even be a sysop. However, he is blocked for one day, for 3RR or so. A@bwiki notices the block and decides to unify the accounts now, so that he will win the unified account. Though A@awiki can talk to a steward and change that, it is still inconvenient for him.

Thus, a block should prevent a user from winning the unified account only if he is blocked indefinitely. Even this way, problems may occur if a block-war happens, but a steward can sort the few remaining problems (also, admins should hear about the new meaning of indefinite block, and may use this tool more carefully if it's possible that the user will be unblocked). Alternatively, blocks should not be considered when choosing the home wiki.
Comment 1 Brion Vibber 2007-09-04 21:03:10 UTC
One possibility would be to let the selection proceed, then simply forbid the merge if the block is in place. That avoids any nefarious activity, while keeping the cleanup job at an easier-to-manage level (asking sysop to fix the block).
Comment 2 Rotem Liss 2007-09-16 04:20:16 UTC
Created attachment 4115 [details]
Patch

This patch implements Comment 1: avoids checking blocks when choosing home wiki, and stops blocked users from accessing Special:MergeAccount instead (it may be a good idea to also show an error page when DB is read-only, as in other special pages, or maybe only several actions: initial, cleanup, and remove if implemented).
Comment 3 Brion Vibber 2007-09-17 13:45:47 UTC
Patch would allow an unblocked account matching a blocked (even permablocked) home account  to go ahead with the merge. Probably better to keep block info in the mix.
Comment 4 Rotem Liss 2007-09-18 04:25:23 UTC
Created attachment 4126 [details]
Patch

This shows an error message if the home wiki is blocked. I'm not sure the implementation is ideal (another parameter for CentralAuthUser::migrationDryRun), but it does the work (though needs i18n, like other messages near it). It is also possible to disable merging of blocked accounts also if not the home account, but this patch doesn't do that.

I'm not quite sure all this blocked users stuff is really needed, though. Why should blocked accounts get a special treatment by CentralAuth? Why should they be prevented from merging? They can log in, change preferences, watch pages, send e-mails (if not blocked from doing that) and so on also using a blocked account. They can't actually use their home wiki, indeed, but they may be able to do that later (if unblocked, automatically by expiry time or manually), and unmerged users shouldn't exist, as I understand that. If the blocked users can't merge their accounts, they won't be able to log into their accounts once strict mode is on (or will it never be on?). They own this user name, they did the edits, and they deserve the unified name as they are not blocked globally (in some cases they may have to be, indeed, but in these cases, I don't see why a user should get their name, and they *should* be recorded, like any user registration, in the new users log, as noted in Bug 11148 - so the admins can block them if they sign in and create an account).
Comment 5 Rotem Liss 2007-11-25 13:39:23 UTC
Created attachment 4380 [details]
Patch

Minor changes in the patch.
Comment 6 Rotem Liss 2008-05-27 16:29:20 UTC
Fixed in r35412.

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


Navigation
Links