Page MenuHomePhabricator

Spam blacklist should provide options like the Title blacklist
Open, Needs TriagePublic

Description

The title blacklist provides options applicable to a specific entry.
The spam blacklist should do the same.

Welcome options would be:

  • autoconfirmed: entry only applies to IPs and new users

workaround: use of bots that revert the additions
limitations of workaround: no warning, not user friendly, less efficient

  • warnonly: after seeing the warning, the user should be allowed to save nonetheless

workaround: use of abusefilter
limitations of workaround: difficult to handle huge lists, less efficient, condition limit

  • errmsg: provides a custom warning for this entry

workaround: having a massive default message that tries to explain as much as it can
limitations of workaround: obvious lack of usability/scalability

Event Timeline

Cenarium created this task.Feb 10 2017, 7:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 10 2017, 7:10 PM
Cenarium updated the task description. (Show Details)Feb 10 2017, 7:16 PM
Cenarium updated the task description. (Show Details)Feb 10 2017, 7:20 PM

This is probably better handled through T6459, a complete overhaul so it
also easier to administer

Hm yeah, but the special page would be hard to implement compared to just adding some options.

Setian added a subscriber: Setian.EditedFeb 22 2019, 9:42 AM

So, a few questions.

  1. Are we anticipating there are just going to be 3-4 options?
  2. Are we going to want to integrate this with AbuseFilter; and if so, how does that affect our design decisions?
  3. Do you mind if we have to create another database table for this?
  4. If we do this as a special page, how do we handle situations where sysops want to insert a line next to an already-existing line, so that similar items are grouped together? Is each line going to be numbered, so that for example, they could number a new line 65 to put it between lines 60 and 70?

I'm trying to figure out if it makes sense to do this as TitleBlacklist-style options or as an Interwiki-style special page. The special page would require a database table. Another option, by the way, is to do this as a json page.

I'm thinking Cenarium is right, that the special page will be the more elaborate route. An advantage of a special page is that it could force sysops to fill in certain fields, e.g. the field for duration of the blacklisting (see T216803). But we could also have a config setting to force that, by making a line have no effect if there's no expiration date set.

Also, who's interested in doing code review of an implementation using (1) TitleBlacklist-style options or (2) an Interwiki-style special page?