Page MenuHomePhabricator

Optionally place a local block when globally blocking
Closed, ResolvedPublic

Description

Author: mike.lifeguard+bugs

Description:
For serial flood vandals, we often global block their IP. It'd be nice to block it on Meta too from the same form. Probably that should be logged as a local block for simplicity's sake. Otherwise, we end up making all these global blocks, only to have them attack Meta while we're still trying to clean up.


Version: unspecified
Severity: normal

Details

Reference
bz17824

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz17824.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 7 2009, 1:04 AM

(Batch change)

These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.

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

We have one of our abusive LTAs seemingly cruising the global block list and comparing it to meta's local block list. Seeing multiple occasions where this vandal will pick a report open proxy from the block list, and if it is not blocked on meta will then use it to abuse and vandalise on meta. A test (opportunity) saw it occur within 33 minutes of a global block without a local meta block.

This addition therefore increases the chance that there is not an omission of a requirement to block, and also cuts out repetitive steps that stewards need to undertake. Especially important during concerted LTA attacks where they have lined up a series of abusable proxies and are in full attack mode.

Thanks.

Just to scope this, I'm assuming you wouldn't want all GlobalBlocks also get blocked on meta, just a subset? Is there a way to determine that automatically, or would you want a checkbox / separate form for this special case?

It would be pretty easy to do this by adding a hook into either the process or the global block form. Or as a javascript gadget.

Personal opinion ... a subset, so this is a conscious decision to apply the 'AND' component

[Statement: Predicating comment that the standard output form [[Special:GlobalBlock]] from a global block will still be the same and give an option to progress to a local block.]

if checkbox

I do not see that a separate form is required, and that a "checkbox" would be suitable if it applies the following meta local block with the conditions

  • Same period
  • Same reason
  • Anon only (this differs as global could be either anon or total)

The question is whether it does:—
a) directly applies this overwriting something local to meta already; or
b) directly applies this unless there is something local and it presents an option to modify; or
c) sets up a local form ready for "do it" application

Personal preference is b) > c) > a)

If a person wants different conditions to be applied, they can then progress manually to the form, as we do currently via the local link.

if not a checkbox

then whether the contents of the [[Special:Block]] are imported and sit in a separate section of the form where different conditions could be applied. That would presumably return any current applicable blocks if the url is in the form

https://meta.wikimedia.org/wiki/Special:GlobalBlock/127.0.0.1

For me, checkbox is fine, though I will prod other stewards for their opinions.

NOTE: If we are playing with the form, can we also look at [[bugzilla:36834]] which is about the exit page from the same form.

Ruslik00 wrote:

This can be done with a gadget that should apply a local meta block.

Change 119915 had a related patch set uploaded by Hoo man:
Optionally place a local block when globally blocking

https://gerrit.wikimedia.org/r/119915

Change 119915 merged by jenkins-bot:
Optionally place a local block when globally blocking

https://gerrit.wikimedia.org/r/119915

Meno25 removed a subscriber: Meno25.Nov 4 2016, 7:11 AM