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

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz5445.
bzimport created this task.Via LegacyApr 4 2006, 12:03 PM
MaxSem added a comment.Via ConduitApr 5 2006, 7:12 PM

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

Platonides added a comment.Via ConduitApr 11 2006, 11:09 AM

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>"

MaxSem added a comment.Via ConduitJun 30 2008, 6:12 PM

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

MaxSem added a comment.Via ConduitOct 11 2008, 12:15 PM

Maybe, it'll get noticed on Bug Monday?

bzimport added a comment.Via ConduitNov 22 2008, 7:25 PM

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?

jayvdb added a comment.Via ConduitApr 28 2011, 2:32 PM

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

bzimport added a comment.Via ConduitSep 1 2011, 2:51 AM

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.

liangent added a comment.Via ConduitFeb 15 2012, 7:25 AM

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.

coren added a comment.Via ConduitMar 28 2012, 4:03 AM

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.
hashar added a comment.Via ConduitMay 4 2012, 6:40 AM

Merged. Should be released with 1.20.

Thanks Mark!

hashar added a comment.Via ConduitMay 4 2012, 6:43 AM

CREDITS / RELEASE-NOTES update made with https://gerrit.wikimedia.org/r/3841

saper added a comment.Via ConduitJun 21 2012, 1:50 PM
  • Bug 31893 has been marked as a duplicate of this bug. ***

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.