Last modified: 2012-11-30 20:16:47 UTC
Based on some testing on MediaWiki.org, page protection and the abuse filter do not work - page protection does not change the ability of all non-blocked users to edit the page and abuse filter does not pick up any edits generated by the visual editor. I believe that the underlying problem is that using the visual editor is not a named action that can be restricted or filtered at the moment. If it was, then it would be possible to assign it to $wgRestrictionTypes and it would be possible for the abuse filter to log it (though the abuse filter does need the addition of some variables or other modification to accept visual editor edits).
Mass-moving items into VisualEditor product
I would not recommend creating a 'usevisualeditor' permission. Rather, permission checks and the usual edit activity paths should be used. AbuseFilter *should* see VE edits exactly the same as edits made through the traditional editing UI or the API.
AbuseFilter does not see them, because I tested some VE edits against my experimental filter but edits made by the VE did not get caught. The 'usevisualeditor' permission would only be a temp solution to the current situation where page protection can't cover it. The other way is to require the 'edit' permission but then that wouldn't suffice in our current scheme of having only admins edit the wikitext directly.
AbuseFilter *should* see them, because to do otherwise is insane. That it doesn't is the bug. :)
Two things: 1.How would an abuse log entry look like? I can't think of anything other than 'Example (talk|contribs) triggered filter 16, performing the action "usevisualeditor" on VisualEditor:Welcome' (etc.). 2.What about page protection?
This will naturally resolve itself when we lift the namespace-specific restrictions on editing the Wikitext and can use the editing API instead of going through the back door, as we do now. This is related to bug 38268 - in that these will both be resolved in the same way.
This was fixed when Roan changed to use the normal edit API rather than bypassing it internally.
Fixed in Gerrit change #31889
Assigning this to a release milestone so it's clear when at the latest to expect it to have been fixed; it may have been fixed beforehand.
