Page MenuHomePhabricator

Notification when account is blocked
Open, MediumPublicFeature

Description

User should be automatically notified when their account is blocked.

There might be situation when block is shorter than users inactivity on project and when blocking admin does not write on user's talk page, user may not notice, when there was any block.

Event Timeline

JAnD raised the priority of this task from to Needs Triage.
JAnD updated the task description. (Show Details)
JAnD added a subscriber: JAnD.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Krenair set Security to None.
Krenair added a subscriber: Krenair.
Mattflaschen-WMF renamed this task from Notification when accout is blocked to Notification when account is blocked.Jul 9 2015, 12:24 AM
Mattflaschen-WMF triaged this task as Medium priority.

Change 264070 had a related patch set uploaded (by Haritha28):
Notification when account is blocked

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

Change 421720 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/Echo@master] Notify user when they are blocked

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

@matej_suchanek Hey! Can I ask that what's up with this task?

Change 264070 abandoned by Aklapper:
Notification when account is blocked

Reason:
Abandoning as this patch is superseded by https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Echo/ /421720/ according to the comments there.

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

@Bencemac: See the two links above: Patch awaiting review.

TBolliger moved this task from Backlog to User blocking on the MediaWiki-User-management board.
TBolliger added a subscriber: TBolliger.

Before this is merged, we should expand it to specify if the block is sitewide or partial. See also: T190350: Epic: ⚡️ Partial blocks

Change 421720 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/Echo@master] Notify user when they are blocked

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

matej_suchanek changed the subtype of this task from "Task" to "Feature Request".
matej_suchanek edited subscribers, added: Ammarpad; removed: TBolliger.

Current features:

  • the message is either "You have been blocked from editing." or "You have been partially blocked."
  • we show the provided reason (unless hidden from public)
  • there is a link to entry on Special:Log/block (unless hidden from public)

Unclear (not implemented) stuff:

  • notification on reblock and unblock
  • including duration to the message
  • wording when the block has expired

Input welcome.

I think it's fine as it's now, but I believe the duration should be included, as as I said in the code review it doesn't involve the complexity you're thinking of.

notification on reblock and unblock

It'll be nice to also be notified of these, but they can be implemented in a separate task. The current patch does satisfy the request of this task, I believe.

wording when the block has expired

I am not sure why you need custom wording, the block log entry object already comes with human-readable durations: 2 days, 3 months, 31 hours.

Also you don't need to revise the message after-the-fact. Notifications serve as record of actions at particular time, they do not need to conform with the present. Notification like "You have been blocked for 1 hour" does not need to be edited after the fact to take into account whether an hour has passed. The block has happened and for an hour, that's a fact, immutable one forever (even if the block were to be lifted before the full expiry duration).

Current features:

  • the message is either "You have been blocked from editing." or "You have been partially blocked."
  • we show the provided reason (unless hidden from public)
  • there is a link to entry on Special:Log/block (unless hidden from public)

This sounds good. Can you post a screenshot of the notification as it looks right now?

Unclear (not implemented) stuff:

  • notification on reblock and unblock

Agree with @Ammarpad that these would ne nice to have but should be in a separate task.

  • including duration to the message

Also agree that it would be good to have the duration in the notification.

  • wording when the block has expired

I don't think there is a precendent (or even provision?) for updating a notification text after it has been sent. Best to not update it retroactively.

Flagging this work for @SPoore, @dbarratt and @Tchanders.

Can you post a screenshot of the notification as it looks right now?

obrazek.png (126×625 px, 9 KB)

Also agree that it would be good to have the duration in the notification.

the block log entry object already comes with human-readable durations: 2 days, 3 months, 31 hours.

Partially true. See BlockLogFormatter::getMessageParameters and Language::translateBlockExpiry. We can get this or just a timestamp.

Hi. Is this now ready to be included in TechNews, or should it wait for next/future week's? (the User-notice tag was added in 2018!)
Whenever it goes in, please suggest wording for the inclusion, e.g. "Logged-in users will now receive a Notification if their account has been blocked."

Also, please document it at https://www.mediawiki.org/wiki/Help:Notifications/Types
Thanks!

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

https://patchdemo.wmflabs.org/wikis/5c839eeb8d/w/

kostajh added a subscriber: kostajh.

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

https://patchdemo.wmflabs.org/wikis/5c839eeb8d/w/

Seems to work :) nice work @matej_suchanek It would be nice to also notify when the user is unblocked, but I suppose we can leave that for another day.

I wanted to note that there's no preference associated with this notification, so users cannot opt-out of receiving it. That seems fine, given what the notification is, but just wanted to note it.

I wanted to note that there's no preference associated with this notification, so users cannot opt-out of receiving it. That seems fine, given what the notification is, but just wanted to note it.

I thought that you put it under echo-category-title-edit-user-talk, since it is a right change (in a certain way).

Is there any wiki where it's acceptable to block a good-faith user without any kind of talk page message?

Personally, I'd much rather see functionality to make sending such messages easy.

kostajh moved this task from Needs Discussion/Analysis to Triaged on the Growth-Team board.

The Growth team talked about this and several team members have doubts about whether this is a useful notification to add. That aside, we think the Trust and Safety Tools Team Backlog team should be involved in the discussion about adding this notification, so tagging that team.

I'm one of the doubtful people regarding this notification.

I understand its goal, which it is to compensate the fact that users don't see the block messages at their talk page (and probably they haven't seen all the previous warning messages, if any). However, as we don't know if users visit their talk page (and find the message at the bottom, and understand it), we don't know either if people open their notifications. I saw people at workshops with 99+ unread notifications...

We have a lot of ways to establish contact with the user, in order to tell them that they go wrong, and they all have flaws:

  • in a diff edit summary, even if it is the worst place to place it (unless if the revert notification is enabled locally)
  • on the user talk page (with the issue that we don't know if people find their talk page and then understand where is the message, do people notice their messages btw?)
  • pings on the article talk page (still at the not natural bottom of the page)
  • mentions on a request for block (indirect ping, not very diplomatic)
  • calling the business company that tries to edit (not joking, I know someone who did it once)
  • etc.

All of these messages are unlikely to be seen by the user. Most of the time, blocked users say that they haven't been warned, or didn't knew that they where editing the wrong way.
On the other side, I regularly hear from patrollers and admins that ar not happy because newcomers don't react to messages. It results into messages that are more red, bigger and with a not-so-nice tone, because most users legitimately believe this would have more impact ("you did it WRONG").

Does this notification resolve the issue? I'm not sure it would: I think most users discover the warnings when blocked, not before. And when blocked, you get a clear message any time you try to edit. A possible improvement would be to explain why one has been blocked. At the moment, the message is a bit dry, with no possible action to understand or ask for help.

So I think we should focus on a proper discussion system instead, where you get your message for sure. Or a notification that warns the user about the fact that they might be blocked if they don't change their behavior. (And we need to know if users read their notifications.)

If we go with the notification, this notification won't change anything to the experience of users if they are editing at the moment of the block, since notifications aren't updated in real time. A user editing a page will notify they they've been blocked only when they will make an action about their edit (quit, save, preview...) or when they will open a new page. If the goal is to warn users about the change on their editing status while they edit, we should work on T34284: Update Echo Notifications in real time without page reloads instead, even if we aren't sure about notifications being noticed (and users not loosing their edits while they leave the page).

It's not just about editors who are blocked who would have gotten a talk page message anyway per normal policy or practice of most (or all?) wikis. At the moment, you can be blocked and if the admin don't tell you wouldn't know anything about it if you don't happen to try and edit during the duration of the block. Such possibly being edge cases doesn't mean we shouldn't worry about it. Secondly, it's also I believe consistency. I believe you get a notification if your user rights are manually modified. Being blocked from editing is effectively if not technically a significant change in userright. The editor concerned should be notified of that by the software and not relied on the admin posting a talk page message telling them.

My motivatin for this request was, when i blocoked very active user (thousands edists) for few hours because of some attack to other editor without message on his takpage, only in block summary. But this user didn't notice block (nor summary), because of few hours inactivity. For this users it would be useful.

I don't think it's a good idea to communicate with users via block summaries. It's short, you can't use much formatting, they can't reply and other users can't comment... also a lot less prominent than talkpage notifications; not all users read their notifications promptly. For user rights changes the notification might be the only way to learn about them (some right changes are not even human-initiated), for blocks you learn about them when you try to edit, anyway.

The Growth team talked about this and several team members have doubts about whether this is a useful notification to add. That aside, we think the Trust and Safety Tools Team Backlog team should be involved in the discussion about adding this notification, so tagging that team.

@mepps, could someone from your team please comment on whether you think this type of notification is worth adding?