Page MenuHomePhabricator

Prevent blocked users from opening the DiscussionTools
Closed, ResolvedPublic

Description

Issues

  • People who are blocked are not made aware that they are blocked [and prevented from commenting] until attempting to publish the comment they just drafted using DiscussionTools. [i]
  • The message people who are blocked see does not describe why they are blocked and what they might be able to do to resolve/address the issue(s) that have led to them being blocked. [i]

Testing instructions

Scenario: person is blocked from editing

  1. Visit a talk page from an account that is blocked from editing.
  2. Notice [ reply ] link are: A) visible and B) appear as they normally do
  3. Click any [ reply ] link on the page
  4. Verify a modal dialog appears with error message similar to this (the exact wording will differ on different wikis):
    image.png (2×3 px, 416 KB)

Considerations

  • Block type: there are a variety of reasons that can cause someone to be blocked (partial block, sitewide block, global lock).
  • Blocky remedy: each block type can, potentially, be resolved differently.
  • Block messaging: there are different ways of delivering the message that informs people that: 1) They are blocked and prevented from commenting, 2) Why they are blocked, and 3) What action(s) they can take to appeal said block.

Open questions

  • What are all of the different reasons (read: "Block types") why someone could be blocked from commenting?
    • partial block, sitewide block, global lock; maybe others
  • How should people experience the message and call(s) to action for each "Block type" ?
    • For all of them: just do whatever visual/wikitext editor does, so that we don't have to handle all the special cases.

i. @matmarex spotted these issues in T270346:

save_failure_typesave_failure_messagecountNotes
responseUnknownblocked20User is blocked. Looks like we show the reply tool interface to blocked users, and only fail when they try posting (and the message lacks details). We should improve this.
image.png (757×2 px, 100 KB)

Event Timeline

META

  • Updating task description with notes from the conversation @Esanders and I had this morning.

Change 674658 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

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

(see T276393 for more details and testing instructions)

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Test wiki on Patch Demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Change 674658 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

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

Ryasmeen subscribed.

Need more info around expected behavior.

Need more info around expected behavior.

@matmarex can you please add testing instructions to the task description?

Testing instructions were written on T276393, it seems. Have you seen that, or are those unclear?

(I'll move them to this task, we should have done it that way in the first place, but most of the discussion about desired behavior happened on that task.)

Testing instructions were written on T276393, it seems. Have you seen that, or are those unclear?

(I'll move them to this task, we should have done it that way in the first place, but most of the discussion about desired behavior happened on that task.)

Thanks @matmarex! My question was more about the points mentioned under Considerations/Open questions section. Do I need to check this for different block types? If so, what are those types and what messages should I expect to see on the modal dialog for each type?

No, I don't think the difference matters in the end. As I understand, we were considering different treatments for different block types, but in end end we decided to just do whatever visual editor does (which in turn just does whatever the wikitext editor does), so all special cases are handled elsewhere and we just display the message.

The block types are partial block, sitewide block, global lock [sic, we call them locks for some reason] – and maybe others I'm not familiar with, but they'd be less common. If you test them, they'll probably result in different error messages, but I don't know what exactly they'll look like.

The block types are partial block, sitewide block, global lock [sic, we call them locks for some reason]

Global locks prevent a user from logging into their account, they're *lock*ed out, so you don't really have to test that as an error condition. However there are global *blocks* (from Extension:GlobalBlocking) that apply to IP addresses and users who are logged in over those IPs.

No, I don't think the difference matters in the end. As I understand, we were considering different treatments for different block types, but in end end we decided to just do whatever visual editor does (which in turn just does whatever the wikitext editor does), so all special cases are handled elsewhere and we just display the message.

The block types are partial block, sitewide block, global lock [sic, we call them locks for some reason] – and maybe others I'm not familiar with, but they'd be less common. If you test them, they'll probably result in different error messages, but I don't know what exactly they'll look like.

@ppelberg/@matmarex: I have listed the scenarios and block types I have tested so far in the Reply tool QA workbook: https://docs.google.com/spreadsheets/d/1ccTSx-v1yb8kvli7e8djFexXL7jThPHE1WomtkCLG6I/edit#gid=437614192

Please double check them for completeness. Some of the workflows I am still not very sure of and a bit confused about, so I left out those ones for now. If you want, I can re-visit those after I get a better understanding.

Couple of issues that I observed:

  1. The modal dialog that appears with the error message is different for sitewide block than the one mentioned in the task description. Should it not be the same as partial block? Or are they triggered from a different source and thus expected?

Screen Shot 2021-04-23 at 12.45.03 PM.png (1×1 px, 206 KB)

  1. For Partial block, the modal dialog for this scenario was almost like the one mentioned in the task description.

Screen Shot 2021-04-23 at 12.55.40 PM.png (654×1 px, 125 KB)

  1. I saw couple times that when a user clicked the "Reply" button for the first time after getting blocked or with a new block settings applied, nothing appeared. No Error message, no dialog. I am wondering if it's the same transient issue we get sometimes where clicking on Reply button first time after logging in sometimes doesn't open the Reply tool even in normal scenario. I couldn't consistently reproduce the issue though.
  1. Also, the text "Loading.." that shows up before the Reply tool opens, was visible for a split second before the modal dialog appeared on few attempts.
  1. The modal dialog that appears with the error message is different for sitewide block than the one mentioned in the task description. Should it not be the same as partial block? Or are they triggered from a different source and thus expected?
  2. For Partial block, the modal dialog for this scenario was almost like the one mentioned in the task description.

These look as expected to me. The messages and their styling can be customized by administrators on each wiki. I looked it up and these two messages are customized on these pages:

As you said, they are different – for whatever reason, the first one has the yellow background and different formatting, and the second doesn't. Possibly no one realized that it needs to be customized separately after partial blocks were introduced.

Compare also to the customizations in production, which also have changed slightly since they were copied to Beta:

  1. I saw couple times that when a user clicked the "Reply" button for the first time after getting blocked or with a new block settings applied, nothing appeared. No Error message, no dialog. I am wondering if it's the same transient issue we get sometimes where clicking on Reply button first time after logging in sometimes doesn't open the Reply tool even in normal scenario. I couldn't consistently reproduce the issue though.

I have never seen this issue. I don't know what to do about this.

  1. Also, the text "Loading.." that shows up before the Reply tool opens, was visible for a split second before the modal dialog appeared on few attempts.

This is expected, it's genuinely loading stuff and we don't know if you're blocked until we load that data.

matmarex moved this task from QA to Ready for Sign Off on the Editing-team (Kanban Board) board.

(Marking as Verified per Rummana's review and my response)

  1. I saw couple times that when a user clicked the "Reply" button for the first time after getting blocked or with a new block settings applied, nothing appeared. No Error message, no dialog. I am wondering if it's the same transient issue we get sometimes where clicking on Reply button first time after logging in sometimes doesn't open the Reply tool even in normal scenario. I couldn't consistently reproduce the issue though.

I have never seen this issue. I don't know what to do about this.

@Ryasmeen: are you able to file a task for the issue you are describing above, assuming you haven't already done so [i]?


i. A quick search of Phabricator did not turn up any results.