Extension:AbuseFilter/Priorities and Design

Extension:AbuseFilter.

Identified Priority Projects (highest impact with minimal dev cost)

 * 1) Global Rules
 * 2) Global Throttle / Variables

Other higher priority issues

 * Variable / List Maintenance - Bugs 38279, 32928 (maybe), and the general idea to merge SpamBlacklist into AF
 * Blocking Options (custom time, custom reason) - Bugs 22523, 29739, 30024
 * Global Blocking - Bug 18660

Design Decisions
see implemented:

Global Rules

 * Most of the development is already done, but untested in production. Some bugs may be opened as issues are identified.
 * Rules will be kept on metawiki. Database access to meta is required, multi-site db setup a requirement for use.
 * Every action triggering AF processing will need to read the global rules from meta's database
 * Log of hits/actions currently live in the central database (i.e., meta), and accessible based on admin permissions in meta

Global Throttle

 * Throttling is currently done with memcache keys, stored by each wiki
 * Global Throttling must use memcache, probably using a shared memcache key
 * Initially, the existing throttle variables should be sufficient if they're globally applied

Open Questions

 * Do we need to keep global rules in memcache for local wiki access?
 * Andrew recommended yes. To store them with a key tied to the central server, flushed when a global rules is updated.
 * Do we need to list global rules locally in rules view?
 * Andrew recommended yes
 * Do we need to filter log view by originating wiki on meta?
 * Andrew recommended yes
 * Do we need links to the central log from local instances? Or show global hits in the local log?
 * Does Automatic Disabling need to happen when local wikis trigger global rules over the threshold?