additional options to rate limit trigger
OpenPublic

Description

Hi,

Unit which needs additional option : "Trigger actions only if the user trips a rate limit"

Task : Add two new options

  1. Option to trip (or not) on first edit

Reason: currently it does not trip on first edit .If I want to display a notice say on first edit and again say third edit then currently it is not possible.

  1. Number of actions to allow should give additional additional option to trip on each numbered trip .

Reason : Currently if I keep trip limite after 3 edits it keeps triping on each edit after third edit. In some rare cases this can be usefull but what primarily needed is say is every 3rds edit or every 10 th edit

  1. Additional message option

Reason currently Abuse filter gives only one message option But where we want to have simpler message on first mistake and a different message on subsequent tris then it should be possible


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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz47493.
Mahitgar created this task.Via LegacyApr 22 2013, 4:32 AM
Nemo_bis added a comment.Via ConduitJun 9 2013, 9:55 AM

Are you speaking of number of submit or of successful edits? I mean, if a filter both warns and disallows it first warns, then disallows on second submit.
You should probably create separate filters, as you want both different conditions and different messages and/or actions. No need to make the interface more complex.

Mahitgar added a comment.Via ConduitJun 9 2013, 10:52 AM

(In reply to comment #1)

Are you speaking of number of submit or of successful edits? I mean, if a
filter both warns and disallows it first warns, then disallows on second
submit.
You should probably create separate filters, as you want both different
conditions and different messages and/or actions. No need to make the
interface
more complex.

a filter both warns and disallows it first warns, then disallows on second submit.<<

: Frankly,I had given thought to submits(By submits I mean attempted edit and not necessarily saved edit) and I had not given serious consideration to situation of disallows but expect that should be possible on numbered submit/attempted edit as per above point no 2 mentioned in bug report.

:Need of point 1 and point 2 remains intact.

:Multiple features may make interface bit complex.But making cluster of multiple filters 1) only few filter managers would understand 2) Cluster of multiple filter is equally complex on user side,if the right person retires maitenence and management is more of complex task for those who did not get involved earlier even after help pages and all .And if some one does not maintain proper notes all the effort by retired person will not be understood by others and most likely will get deleted over time.We have 700 wikis under umbrella and we need to think about every situation

Krenair added a comment.Via ConduitJun 9 2013, 12:51 PM

(In reply to comment #2)

We have 700 wikis under umbrella and we need to think about every situation

Yeah if you completely exclude every non-wikimedia wiki running AbuseFilter.

werdna removed a subscriber: werdna.Via WebDec 10 2014, 6:17 PM
Mahitgar added a comment.EditedVia WebThu, Jun 11, 1:12 PM

Though not dirctly related issue taking note of bug T100638; this bug suggests that there is some chance that some false positives are coming on not saved (probably preview related) attempted edits, that issue needs further study.

Add Comment