Allow customizing blocks and its settings for each abuse filter
Closed, ResolvedPublic

Description

Currently AbuseFilter uses a default block expiry time defined by the variable $wgAbuseFilterBlockDuration in the configuration file.

It would be good if the settings of the block and its expiry time could be configured locally for each filter when creating one (or modifying it) so we could use different block settings for different filters rather than only one expiry time/settings for all of them.

Also, other block parameters (such as whether the user is blocked form editing their own talk page, etc.) should be set per filter.

Details

Reference
bz30024
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz30024.
bzimport added a subscriber: Unknown Object (MLST).

mayurdce wrote:

+1, Another problem is that in case of Range block this parameter doesn't work.It blocks a range indefinitely.

unanswers wrote:

+1 for this. Also, a way to specify a different block setting for a user and an IP address would be handy.

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

Importance changed to normal:normal. Several users have expressed that this would be useful.

(In reply to comment #5)

Several users have expressed that this would be useful.

Still it's an enhancement (new functionality).

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJul 6 2015, 12:23 PM
Meno25 removed a subscriber: Meno25.Feb 8 2016, 7:47 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 8 2016, 7:47 PM
MGChecker updated the task description. (Show Details)May 25 2016, 9:18 PM
MGChecker removed a subscriber: wikibugs-l-list.
MarcoAurelio renamed this task from AbuseFilter: per-filter customizable block settings to Allow customization of blocks for each abuse filter.
MarcoAurelio raised the priority of this task from Normal to Needs Triage.
MarcoAurelio renamed this task from Allow customization of blocks for each abuse filter to Allow customizing blocks and its settings for each abuse filter.
MarcoAurelio added subscribers: Ladsgroup, Huji, Yamaha5.
MarcoAurelio added a comment.EditedJan 18 2017, 10:26 PM

Issues to avoid: user hits two filters set to block but with different settings each. Once the account triggers the first blocking filter, it should stop or if triggering several blocking filters, issue the more severe block of those triggered and discard the rest.

Huji triaged this task as High priority.Aug 22 2017, 6:30 PM
Restricted Application added a project: User-MarcoAurelio. · View Herald TranscriptAug 22 2017, 6:30 PM
Huji updated the task description. (Show Details)Aug 22 2017, 6:31 PM

Some personal considerations: if a user hits two filters, the more severe block should be issued. Also, as said above, it would be useful to have different block settings for IPs and users: for many kinds of vandalism (e.g. blasphemy) you want to issue users an infinite block, while for IPs this isn't of course possible. If it's easier to implement, it would also be useful to only choose between some predetermined block durations, e.g. 15min, 4h, 1d, 1w, infinite.

Daimona claimed this task.EditedFeb 20 2018, 9:46 AM

Working on this. I already managed to solve (more or less) the main troubles. In case of conflicting blocks, the longest is issued, and for each filters users can specify a duration for anons and one for registered users (from a dropdown with the 5 options in my previous comment). Now, apart from reordering code and removing redundancies, I need to solve some backward compatibility issues and handling the old globals for block duration, which I hope to do before tomorrow. Another thing is to handle rangeblocks: I didn't touch them, nor I'm sure about how to treat them.

Precisation: I'm not sure how to handle rangeblock also because I never used it, nor it's used in many wikis, and I don't want to mess up. I'd prefer it to be handled in a separate task, if it's not a problem.

Change 412892 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Allow customizing block durations for each filter

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

Huji moved this task from To Triage to Not ready to announce on the User-notice board.
Huji closed this task as Resolved.Mar 9 2018, 3:22 AM
Huji removed a project: Patch-For-Review.

It is now possible to both select the duration of the block (separately for anonymous users and registered users), and block the user/IP from editing their own talk page. I think these are the key features from Special:BlockIP that would have been needed here, so I am going to mark this as Resolved.

User notice: It is now possible to specify the block parameters for each filter in AbuseFilter. The parameters include block duration (separately for anonymous and registered users), and whether the user should be blocked from editing their own talk page. See T32024 and T170014

Change 412892 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Allow customizing block durations for each filter

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

Thanks @Huji for merging. Since the change is relatively quite big and there may be (hopefully not, but who knows) backward compatibility bugs, I'd also add to tech news an explicit notice to report any bug in phab.

@Huji: Thank you very much!

Huji added a comment.Mar 9 2018, 11:55 PM

@MGChecker it is truly a team effort, and @Daimona has been a key part of the team as well.

Indeed, everyone's work is needed here :-)

Does this respect the default values we state at $wgAbuseFilterBlockDuration / $wgAbuseFilterAnonBlockDuration at wmf-config/abusefilter.php? Would they cause conflicts with each other? Are those variables needed now that we have this feature? Thanks.

@MarcoAurelio Those variables are still used, both for 1 - blocks coming for "old" filters (without custom duration) and 2 - to set a default dropdown value the first time you open an "old" filter or you create a new filter. There shouldn't be any conflict, and they're needed both actively (case 1) and passively (case 2), thus they must be kept.

Thanks for clarifying.