Last modified: 2014-10-14 12:07:24 UTC
I would like to request that some flag or other indicator be added such that abuse filter rules can tell whether the edit is coming from VE or from the source editor. Because the abuse filter tends to encourage different sorts of editor errors, it would be useful to know which interface is being used when editing. For example, a nowiki tag added by the source editor is almost certainly intentional, while a nowiki added by VE is probably an accident and should be tagged for inspection.
Both AbuseFilter and VisualEditor use change tags. It might be possible for AbuseFilter to use VisualEditor's tag if AbuseFilter runs after, though I don't see tags mentioned at https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format
This would need AbuseFilter to be extended to understand tags (or, to understand VisualEditor, which seems a less satisfying and extensible way of achieving this).
Can the abusefilter detect veaction=edit. Using that and we could block edits which insert nowikis from the VE when they are almost always in error and allow them from wikitext editor, when they are normally ment.
Wait, if the AbuseFilter is going to understand tags, and already applies tags, what order will filters run in? What if a later filter applies a tag that would have triggered an earlier filter? Should MW just keep re-running the filters until everything's been triggered?
I'm pretty sure it's impossible to do this since any kind of tags can be only added after an edit is saved (ChangeTags::addTags() function requires the edit to have a know rev_id which implies that it already exists in the database).
(In reply to comment #5) > I'm pretty sure it's impossible to do this since any kind of tags can be only > added after an edit is saved (ChangeTags::addTags() function requires the > edit to have a know rev_id which implies that it already exists in the > database). Does AF's hook happen after VE's save (which applies tags), at least?
AF's hook attempts *during* save, in EditPage#runPostMergeFilters and ApiEditPage#execute (the second one is only used to present nicer information about saving failure in the API and is what VE is actually hitting, but that doesn't matter here). VisualEditor's ApiVisualEditorEdit calls the edit API first (#saveWikitext) and only after it has succeeded calls ChangeTags::addTags to add the tags to the edit. So to make this work, we'd have to adjust code in core, in AbuseFilter and in VE to allow passing change tags with the edit API call or in some magical way before it. It'd make the logic really awkward (since tags could now be added before/during and after making the edit, and the second kind would be invisible to VE) and likely introduce back-compat issues (for the same reason). There are also requests to make the tags editable by users (bug 18670), which generally seems like a pretty good idea, but complicates the issue here even further. So to summarize, I don't see this happening, but feel free to prove me wrong if you think you can tackle this :)
s/attempts/happens/, of course.
s/invisible to VE/invisible to AF/. I swear, I did proofread that. :)
The original request was merely for the AbuseFilter to somehow be made aware whether or not an edit had come from VE as opposed to source editing. For example, the Abuse Filter is aware of "action=" but not "veaction=". At present "action=edit" and "veaction=edit" look identical to the AbuseFilter. I think the suggestion that AbuseFilter should somehow be allowed process tags generated by other entities is actually an unnecessary (and more complicated) diversion.
(In reply to comment #10) > The original request was merely for the AbuseFilter to somehow be made aware > whether or not an edit had come from VE as opposed to source editing. > > For example, the Abuse Filter is aware of "action=" but not "veaction=". At > present "action=edit" and "veaction=edit" look identical to the AbuseFilter. Adjusting comment accordingly. > I think the suggestion that AbuseFilter should somehow be allowed process > tags generated by other entities is actually an unnecessary (and more > complicated) diversion. Sure.
