Page MenuHomePhabricator

Provide ability to watch for changes on filters
Closed, DuplicatePublic

Description

Changes to filters should show up on watchlist of users with permission for editing them or there should be a way to add public filters to our watchlist

I like to review changes to filters to look for badly coded regexes or misplaced parenthesis, etc... but this requires one to remember of the existence of
https://en.wikipedia.org/wiki/Special:AbuseFilter/history
from time to time.

Details

Reference
bz60588

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:54 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz60588.
bzimport added a subscriber: Unknown Object (MLST).

Just throwing this in here that a bot is currently doing this for public changes on enwiki at User:MusikBot/FilterMonitor/Recent changes. In the interim I can make this happen on other wikis if they are interested. Obviously there's no safe way to do this for private filters, so some sort of core functionality for that would be nice :)

He7d3r set Security to None.
He7d3r removed a subscriber: wikibugs-l-list.
Daimona moved this task from Backlog to Future on the User-Daimona board.
Daimona subscribed.

Being a widely requested feature (or so it seems), I'll give it a look.

What Huji said in T216100#4953178 could apply here, but it could be even easier: SpecialWatchlist basically queries the recentchanges table, and extensions may add extra types for the rc_type field. For instance, Flow adds RC_FLOW. However, while AbuseFilter edits show up in recentchanges, they have the same type as usual logs (they're distinguished via rc_log_type), and thus they should show up without doing anything further. The only thing left to implement should be an interface to add/remove filters from watchlist. Any ideas about where it could be located?

Daimona lowered the priority of this task from Medium to Low.Feb 23 2019, 10:29 AM

Ah, actually we have another problem: the Watchlist doesn't have support for special pages. Using WatchAction::doWatch breaks on WikiPage::factory, while calling User::addWatch directly fails upon trying to retrieve the associated talk page. Although not being able to watch special pages is a core limitation, it also makes sense, as AbuseFilter is a special case. I'm unsure what the best solution would be: remove core limitation? Add a hack to AF (argh!)?
At any rate, IMHO this is low priority because (quoting Huji) it's a "nice to have", and currently we have several important patches under review to address major problems.

@Daimona a potential, though potentially controversial, solution would be to make AbuseFilter a namespace, with the "notes" section being the talk page. Editing in that namespace would require the current rights to edit abusefilters (like the edit requirements imposed on the MediaWiki, Gadget, Gadget-definition, etc. namespaces). Thus, they would no longer be "special pages" in the sense for watching changes, and would have talk pages. There is probably a more elegant solution though.

Yes, that (or a variation of it) would possibly help solve several other tasks, e.g. T155468 and T155467. However, it's a lot of work to do, and IMHO it's very low priority (probably lowest).