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).

rotemliss wrote:

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).

attachment patch ignored as obsolete

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.

rotemliss wrote:

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).

attachment patch ignored as obsolete

rotemliss wrote:

Patch

Minor changes in the patch.

Attached:

rotemliss wrote:

Fixed in r35412.