Page MenuHomePhabricator

Homepage: improve error handling for questions that trigger abuse-filter
Open, Needs TriagePublic

Description

Note: The issue is reported for entering Abuse-Filter-triggering text into Help panel and Mentorship panel.

If adding a question is catched by an abuse filter, user is given a nothing-telling message, see screenshot.

User should be given a warning that's configured in the abuse filter that issued the warning, as it happens for normal edits, see this screenshot:

The specifications for this task are:

  • If the question can't be posted because of an abuse filter, then our existing design for errors would show the abuse filter's message.
  • If the question can't be posted because user has logged-out: "You are not currently logged in. Please log in to your account to ask your question." In this case, "log in" is a link to https://en.wikipedia.org/w/index.php?title=Special:UserLogin.
  • If the question can't be posted because page is protected: "Community Help Desk questions are not available at this time. You can try again later or you can visit Community Help Desk in your browser and add your question manually." The second "Community Help Desk" should link to the page, like in the default message.
  • If the question can't be posted because of an edit conflict or for any other reason, then our design would do exactly what it does now.

Details

Related Gerrit Patches:
mediawiki/extensions/GrowthExperiments : masterQuestionPoster: Return result for non-exceptional errors

Event Timeline

Urbanecm created this task.Apr 30 2019, 4:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 30 2019, 4:35 PM
Etonkovidova updated the task description. (Show Details)Apr 30 2019, 5:42 PM
JTannerWMF added subscribers: Etonkovidova, JTannerWMF.

This needs a product decision, but @Etonkovidova has an approach to this you should discuss.

To fill in some more detail: my comment was that this currently works as designed (see "Notes on the design" in T209318). An alternative proposal would be to pass through whatever error is set on the backend for the user to read. The advantage to doing so is that the user is informed (hopefully) about what went wrong and why their question didn't post. One could argue that the disadvantage is the newcomer may not understand the error message. We could consider showing both the current error message and the specific error message below it, but I'm not sure how well that would all fit within the help panel or mentorship/help modules.

revi added a subscriber: revi.May 1 2019, 4:12 AM

If we are really worried about showing cipher-ish error messages to newbies, maybe show the current fail message with an "advanced" button to show the real error (abusefilter, read-only, whatever)?

@Aklapper Not fully sure this is relevant to T40638: Interface messages needing rewording or documentation and other issues with existing messages (tracking). This is not about a interface message - unless I'm wrong, this currently shows an interface message intended for "general failure", which is phrased correctly. The proposal is to create a new message just for AF error, and show it in case of this error.

MMiller_WMF renamed this task from Improve error handling for abuse-filter catched edits to Homepage: improve error handling for abuse-filter catched edits.May 8 2019, 8:42 PM
MMiller_WMF added subscribers: Catrope, SBisson.

@kostajh -- is it possible or advisable to detect that the posting error is because of an abuse filter, and then to conditionally show a different message to the user when they are caught by the abuse filter than for the rest of errors?

Etonkovidova renamed this task from Homepage: improve error handling for abuse-filter catched edits to Homepage: improve error handling for quesitons that triggered abuse-filter .May 8 2019, 8:53 PM
MMiller_WMF renamed this task from Homepage: improve error handling for quesitons that triggered abuse-filter to Homepage: improve error handling for questions that trigger abuse-filter .May 8 2019, 9:00 PM

@MMiller_WMF yes it is possible to surface only the abuse filter errors. Whether it's advisable to show the details of those and not others, I'm not sure. I would be in favor of starting with showing Abuse Filter errors then re-evaluating if we want to show all errors.

@kostajh -- okay, so here's what I was thinking:

  • If the question can't be posted because of an abuse filter, then our existing design for errors would show the abuse filter's message.
  • If the question can't be posted for any other reason, then our existing design would do exactly what it does now.

How does this sound?

Is there only one global abuse filter error message? Or can different filters send different messages?

Urbanecm added a comment.EditedMay 9 2019, 4:51 AM

Is there only one global abuse filter error message? Or can different filters send different messages?

Any filter can send any message. Even more, each filter can prohibit the edit to be saved, or just warn the user before saving. It is up to you if we want to show any difference between warning and edit cannot be saved cases :).

EDIT: Not sure what you meant by "global", however, there are both global (applies on multiple wikis, IIRC all but large, which includes cswiki those days) and local (applies only on one wiki) filters. IIRC users can't tell which one matched without going through logs. I don't think there should be any design difference.

@kostajh -- wanted to check back on what you think of my proposed idea two comments above.

If the question can't be posted because of an abuse filter, then our existing design for errors would show the abuse filter's message.
If the question can't be posted for any other reason, then our existing design would do exactly what it does now.

How does this sound?

That sounds OK. The other reasons would include: 1) user has logged-out (but hasn't reloaded the page), 2) edit conflict on the help page; 3) page is protected. Maybe it does make sense to surface all error messages, and not just AbuseFilter ones.

Is there only one global abuse filter error message? Or can different filters send different messages?

As @Urbanecm mentioned, they can be customized. For example, https://en.wikipedia.org/wiki/Special:AbuseFilter/3 uses this message https://en.wikipedia.org/wiki/MediaWiki:Abusefilter-disallowed-blanking

Okay -- I think we should generally do this plan. I ran the numbers, and only 2 submission attempts out of 90 (that are still in the event.helppanel table) resulted in a "submit-failure". So this is not a common occurrence. But in case it is easy to detect which kind of failure the user encounters, I quickly wrote these error messages for the scenarios you listed:

  • User has logged-out: "You are not currently logged in. Please log in to your account to ask your question." In this case, "log in" is a link to https://en.wikipedia.org/w/index.php?title=Special:UserLogin.
  • Edit conflict: "An error occurred when trying to post your question. You can try again or you can visit Community Help Desk in your browser and add your question manually." This is the same as the default error message.
  • Page is protected: "Community Help Desk questions are not available at this time. You can try again later or you can visit Community Help Desk in your browser and add your question manually." The second "Community Help Desk" should link to the page, like in the default message.
MMiller_WMF removed MMiller_WMF as the assignee of this task.Jun 6 2019, 12:03 AM
MMiller_WMF added a subscriber: MMiller_WMF.

This task is ready for development.

MMiller_WMF updated the task description. (Show Details)Jun 6 2019, 12:05 AM

Change 530085 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: Return result for non-exceptional errors

https://gerrit.wikimedia.org/r/530085

@MMiller_WMF I've put this into code review but a few notes/comments/questions for you, since what I've submitted is a little different from what you specified in T222204#5238771

  1. The patch will show the abusefilter message directly to the user, just as if the user had attempted to save an edit in VisualEditor (like the screenshot in this task description). AFAICT this is the most important item to address in this task.
  2. The patch will show the "You are blocked" message directly to the user, in the same way that a blocked user sees the message when they try to save via VE
  3. The patch does not show any more detail to a logged-out user, it shows the generic error message we currently show when there's a problem. There are two reasons for this: 1) the situation where a user opens the help panel (they are logged-in, otherwise they wouldn't see it) then their session expires and they try to post a question some amount of time later has to be pretty rare if non-existent in production, and 2) adding code to handle this case would be annoyingly complicated, so I'd prefer to not add the additional complexity for that, if you agree.
  4. The patch shows "This page has been protected to prevent editing or other actions." (in the wiki's content language) when the help desk is protected or the user attempts to post to a mentor's protected talk page via the mentorship module. This is not ideal from a usability perspective since the user would think "This page" is the page they have open rather than the help desk, but similar to the point above, handling this case separately could be kind of difficult to implement cleanly. How often do we think this situation might occur? Should we try to address this?
  5. Edit conflict, I haven't tested this but I believe it would show the edit conflict message rather than the generic message. Similar to the point above, it might be a little confusing to the user since they would have to intuit that the message is talking about the help desk page rather than the page they are looking at with the help panel open.

The alternative to the caveats above is to add the custom translation strings as requested in the task description, but I thought I'd see if what I've proposed here is satisfactory before proceeding with that.

Tgr added a subscriber: Tgr.Aug 22 2019, 9:20 AM

Ideally in the case of an edit conflict the message should just be reposted.

@kostajh -- I'm late in responding to this, but all the comments you made sound fine to me. Let's proceed and test out what you've written. @Etonkovidova will let us know if things seem weird.

kostajh removed kostajh as the assignee of this task.Oct 15 2019, 12:58 PM
kostajh edited projects, added Growth-Team; removed Growth-Team (Current Sprint).

Moving out of current sprint, and can pick this up again at a later time. For now I'm unassigning myself.

kostajh moved this task from Inbox to Upcoming Work on the Growth-Team board.Oct 15 2019, 12:58 PM