Steps to replicate the issue (include links if applicable):
- Go into iOS app and trigger abuse filter when editing
What happens?:
- If the message is at MediaWiki:Abusefilter-warning-foo, the user will see <abusefilter-warning-foo>,
What should have happened instead?:
- User should see contents of that page
Software version (skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
The styling of it should be the same as EditNotices. You can draw inspiration from the Android implementation.
Design
An AbuseFilter gets triggered when an editor tries to publish a low quality edit that gets detected and a warning message gets sent to the editor (all content of the message should be displayed in the modal on mobile). They could also be blocked, or the edit can be disallowed in a variety of ways (more information found in Extension:AbuseFilter/Actions ).
- If the alert message recommends a change but doesn't block the edit it would be displayed as an alert modal with two options 'Go back' or 'Publish anyway'.
- If the editor is unable to publish the edit after triggering a different type of an AbuseFilter, then they will see a warning modal similar to a block message, where they are only able to acknowledge the alert and are brought back to the editing screen.
Screens
| Editor taps on pencil on article view | Editing screen | Editor taps 'Next' and sees a 'Preview' | Editor can add an 'Edit Summary' | AbuseFilter triggered, warning message sent but editor may still publish or go back to editing screen | AbuseFilter triggered and editor cannot publish the edit |
 |  |  |  |  |  |
Note for QA
As a part of this, please regression test page protection logic on our editor and article description editor, to be sure it still works as before. Our plan is to release blocked work, edit notices and abuse filter work before we pick up T313772.