| 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.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T125653 Create new types of notifications | |||
| Resolved | Feature | neriah | T100974 Notification when account is 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 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-Team 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!
Change #421720 abandoned by Matěj Suchánek:
[mediawiki/extensions/Echo@master] Notify user when they are blocked
Reason:
I would appreciate it if it were possible to discuss this feature request again. (It seems that the discussion two years ago didn't reach a conclusion).
Changes to account rights send Echo notifications, although on many wikis it is also customary to update users about such changes on their talk page. In the case of blocks, although there is greater emphasis on sending a message to the user’s talk page, it still sometimes happens that the user does not receive a notification about the block. This can also occur in cases where a discussion took place on a page in the Wikipedia namespace and, in the end, the user was blocked, so the administrator did not see a need to explicitly state that a block had been applied, while the user themselves was not following the page closely enough. Another case I have encountered several times is when the block details were changed so that the user was also blocked from editing their own talk page, and they did not receive any notification about this or the reason for it.
I can submit a patch myself, but I would rather not work on something that is controversial and may not be approved.
Could the responsible team discuss this and reach a decision on whether this feature will be accepted or not? Thank you.
Thanks @neriah, speaking on behalf of Product Safety and Integrity team (who own blocking) we would approve this feature and will be happy to provide code review for the patch(es).
Please feel free to add me to any patches
I would suggest that you make the block notification optional, so that wikis who don't like the feature and would prefer to rely on block notices on the talk page can have it disabled on their wiki. However, it should be fine for to be enabled by default
Additionally, it may be worth considering not sending this notification out via emails to avoid letting sockmasters know about blocks on accounts they keep as sleepers
Change #1299444 had a related patch set uploaded (by Neriah; author: Neriah):
[mediawiki/extensions/Echo@master] echo: add echo notification when account is blocked or unblocked
I guess it is more probable that a sockmaster won't give an e-mail address at all, and anyway I prefer helping legitimate users even if this will sometimes decrease the punishment of vandalists.
It's more probable they will give an email address from my experience on English Wikipedia. There are several LTAs I know of who set email addresses on their accounts
Even if they have an email address, would they actually benefit from receiving a notification when they're blocked? or is your concern mainly about saving resources?
At the end of the day, it's your decision, so if you think email notifications should be disabled by default, I'll do that. however, I think that would be unfortunate, because for newly blocked users, an email notification is likely to be more effective than an Echo notification.
Yes they would benefit, because a common pattern is for LTAs to log into each sleeper to try to use it to edit. If an email is sent, then they don't need to log into these blocked accounts and so can go straight to an account they know isn't blocked. This then makes it not possible for a CU to link the unblocked sleeper to the other accounts that were blocked based on CU evidence
At the end of the day, it's your decision, so if you think email notifications should be disabled by default, I'll do that. however, I think that would be unfortunate, because for newly blocked users, an email notification is likely to be more effective than an Echo notification.
I'd personally have email notifications disabled by default
lol, I'm not a CU on any wmf wikis, so I don't really think along those lines... I'll change the default to disabled, although I still feel it's a bit unfortunate for users who get blocked because of an inappropriate username or similar issues.
Yeah, for sure it's unfortunate for good-faith users but hopefully if they log in or read a page they will see the notification
Adding Product Safety and Integrity sprint to track our code review on the patch and so it doesn't get forgotten if I am away
Change #1302969 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/Echo@master] Add tests for block and unblock notifications
Change #1299444 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Add echo notification when account is blocked or unblocked
Change #1302969 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Add tests for block and unblock notifications
@Dreamy_Jazz is there anything that changed to move this task from Not ready to announce to To Triage on the User-notice board? Has this task evolved?
If it is ready to go on wikis, what would be the announcement?
THanks!
Yes, the feature will be going to wikis next week
If it is ready to go on wikis, what would be the announcement?
I'm not sure on the announcement, probably something like "Users who are blocked or unblocked will get a notification when this happens. This can be disabled per-wiki if desired"
Can you document the change on https://www.mediawiki.org/wiki/Help:Notifications/Types please?
When would it be deployed to the wikis, next week?
Sure
When would it be deployed to the wikis, next week?
Yes, as I specified above it will be next week's train this goes out in