Page MenuHomePhabricator

Remove autoblocks when a user is unblocked
Closed, ResolvedPublic

Description

Author: rotemliss

Description:
Sometimes, we block a user, he tries to edit a page and his IP address is
automatically blocked, then we unblock him and forget to unblock his IP address

  • or we waste our time by searching the automatically-blocked addresses to

unblock them.

I suggest to automatically unblock the automatically-blocked IP address, when
unblocking a user.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=13131

Details

Reference
bz5445

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 9:09 PM
bzimport set Reference to bz5445.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 1503
patch for unblocking autoblocked IPs when unblocking user

I guess this patch can help. Though it uses some hacks.

attachment autoblocs.patch ignored as obsolete

I think it would be more valuable having mediazilla showing at the unblocking a
list like:

This block produced the following automatically blocks:
*127.0.0.1 (unblock)
*#4564 (unblock)
*127.0.0.2 (unblock)
*etc.

where unblock is a link to automatically unblock that user/ip. Maybe with an
auto reason "Unblocking autoblock done due to <ip originally blocked>"

Created attachment 5036
Patch

Here's my proposed fix. It changes the meaning of ipb_user - now it is set to id of user who caused the autoblock instead of zero. I made removing autoblocks an option in unblock dialog, though in practice it should be used in 99% of cases so probably it won't hurt if that option is eliminated completely and autoblocks are always removed.

I need some advice regarding API format. I currently made it in form &removeautoblocks=1, and assume that autoblocks should be removed if that option is omitted, but this probably contradicts with the current API practice where it usually looks simply like &removeautoblocks. But I wanted this option to be active by default.

attachment UnblockAuto.patch ignored as obsolete

Maybe, it'll get noticed on Bug Monday?

mike.lifeguard+bugs wrote:

(In reply to comment #3)

Created an attachment (id=5036) [details]
Patch

I need some advice regarding API format. I currently made it in form
&removeautoblocks=1, and assume that autoblocks should be removed if that
option is omitted, but this probably contradicts with the current API practice
where it usually looks simply like &removeautoblocks. But I wanted this option
to be active by default.

Why can't you have it enabled by default for api, and use &noremautoblocks to *not* remove them?

Massive time saver here. patch is a bit rotten, but can be saved..

john wrote:

Comment on attachment 5036
Patch

Marking this patch as obsolete. Unfortunately (Or fortunately, depending on your viewpoint =) ) the Block class has been refactored and no longer allows arbitrary setting of properties.

I propose to reuse the ipb_auto field and change it to an unsigned int: when it's 0, this block is manual; when it's not 0, it's an auto block created from a manual block whose number is ipb_auto.

Possible implementation submitted for review (gerrit change #3841)

  • New column instead of overloading ipb_auto for saner migration (per Tim)
  • No option to not remove the autoblocks at the moment; honestly, I can't think of a scenario where this would make sense.

Merged. Should be released with 1.20.

Thanks Mark!

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