| JAnD | |
| Jun 1 2015, 11:22 AM |
| F31952699: obrazek.png | |
| Jul 29 2020, 9:48 AM |
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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Notify user when they are blocked | mediawiki/extensions/Echo | master | +124 -0 | |
| Notification when account is blocked | mediawiki/extensions/Echo | master | +18 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T125653 Create new types of notifications | |||
| Open | Feature | None | T100974 Notification when account is blocked |
Change 264070 had a related patch set uploaded (by Haritha28):
Notification when account is blocked
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
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.
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
Current features:
Unclear (not implemented) stuff:
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).
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?
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:
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 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.
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:
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.
@mepps, could someone from your team please comment on whether you think this type of notification is worth adding?
As a quick note, Factotum allows blocking/unblocking a user (with the most common/basic options, no partial blocks) while posting a on their talk page. (option is hidden behind the magnifying glass) Edit summary also becomes block summary and block summary automatically links the comment.
Perhaps there are more scripts that can do this.
Unless I misunderstand, this is only human-readable for humans who understand English.
@kostajh I'm not sure I understand how the TST team can help here, let's get together and clarify?
Maybe it's something more in Anti-Harassment team's domain (cc @Niharika). In the Growth team, we had some team members who thought it wasn't very useful to show a notification to a user when they're blocked. As #trust-and-safety-tools-backlog and Anti-Harassment both operate more in the realm of "block activity" (not something that Growth team has focused on much at all) we though TST should be involved in the discussion. @KStoller-WMF maybe you have more to say about it?
In T100974#8902679, @kostajh wrote:
@KStoller-WMF maybe you have more to say about it?
It sounds like in certain cases this notice will be helpful, but in other cases the notice will just seem like an additional scolding from the system. But I think ultimately @Niharika / AHT gets to make the call here.
Personally, I favor providing more information rather than less. At least on desktop, I don't see any visual indication that I'm blocked until I try to edit again; on Minerva, I see a lock icon next to "Edit" but no explanation as to why it's there. I feel like if I was blocked, I'd want to get a notification about it.
Test wiki on Patch demo by KHarlan (WMF) using patch(es) linked to this task was deleted:
@matej_suchanek: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!