Page MenuHomePhabricator

Mute: Add links to the Tools menu on user pages to mute/unmute user
Closed, ResolvedPublic2 Story Points

Description

Currently, to configure the mute lists, users must go to Special:Preferences and add the username manually to both the lists. A more streamlined user experience would be to use the Special:Mute page (from T218265: Mute: Add links to disable email and mute specific user to emails sent via Special:EmailUser).


Acceptance criteria

  • In the Tools menu in the left rail (on LTR language wikis), add a new link: Mute preferences
  • This link should only appear for logged-in users and were registered relevant users are found (E.g. Contributions, User talk pages, etc )
  • Clicking on the link should take the user to Special:Mute with the mute checkboxes pre-checked based on current settings of the mute lists:

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added a project: Growth-Team. · View Herald TranscriptMar 13 2019, 9:42 PM
Restricted Application added subscribers: MGChecker, Aklapper. · View Herald Transcript

Before doing this, I think we should merge the list, that way we can just say "Mute this user" and "Unmute this user" which is similar to other systems.

Before doing this, I think we should merge the list, that way we can just say "Mute this user" and "Unmute this user" which is similar to other systems.

I agree that this would make the end-user experience a lot more straightforward.

JTannerWMF moved this task from Inbox to External on the Growth-Team board.Mar 19 2019, 5:55 PM
Niharika renamed this task from Mute: Add links to the Tools menu on user pages to mute/unmute emails and notifications to Mute: Add links to the Tools menu on user pages to mute/unmute user.Apr 17 2019, 10:08 PM
Niharika triaged this task as Medium priority.
Niharika updated the task description. (Show Details)
Niharika moved this task from Backlog to Cards ready to be discussed on the Anti-Harassment board.
Niharika updated the task description. (Show Details)May 2 2019, 6:43 PM
Niharika set the point value for this task to 2.May 2 2019, 6:46 PM

I think I prefer Mute options now that I think about it. :P

I think I prefer Mute options now that I think about it. :P

That was my initial thought. :) Will change.

Niharika updated the task description. (Show Details)May 2 2019, 10:00 PM
Niharika updated the task description. (Show Details)May 31 2019, 10:34 PM
dmaza claimed this task.Jul 8 2019, 7:49 PM
dmaza moved this task from Ready to In Progress on the Anti-Harassment (The Letter Song) board.

Change 522017 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Add mute preferences link to the tools menu

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

dmaza updated the task description. (Show Details)Jul 11 2019, 4:18 AM

Change 522017 merged by jenkins-bot:
[mediawiki/core@master] Add mute preferences link to the tools menu

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

dom_walden added a subscriber: dom_walden.

On the side rail, I see the link for Special:Mute/$user on:

  • User:$user
  • User_talk:$user
  • Special:Contributions/$user
  • Special:Block/$user
  • Special:CentralAuth?target=$user

Assuming $wgEnableSpecialMute = true. Neither $wgEnableUserEmailBlacklist nor $wgEchoPerUserBlacklist has to be true, which means you can see this link even if there is nothing you can do with it. I don't know why you would configure your wiki like this, though.

Also tested with an RTL username on wikis with RTL and LTR content language.

Also with non-default interface language (incl. RTL). (There are no translations yet, though.)

Link only appears when the user you want to mute exists locally. This makes sense as Special:Merge/$user won't work if $user does not exist locally, either.

Did not see any errors in the logs.

Oh, you do also see the Special:Mute link on your own user, user_talk, etc., pages, taking you to Special:Mute for your own user. I don't know what happens when you mute yourself. Not sure if this is a problem.

Assuming $wgEnableSpecialMute = true. Neither $wgEnableUserEmailBlacklist nor $wgEchoPerUserBlacklist has to be true, which means you can see this link even if there is nothing you can do with it. I don't know why you would configure your wiki like this, though.

@dmaza I don't think we should show the link if the page is going to throw an error anyways. It's effectively an access denied (and perhaps we could use that mechanism?).

Oh, you do also see the Special:Mute link on your own user, user_talk, etc., pages, taking you to Special:Mute for your own user. I don't know what happens when you mute yourself. Not sure if this is a problem.

I guess that's technically allowed in Special:Preferences as well? not sure what it would do either.

dmaza closed this task as Resolved.Jul 23 2019, 7:48 PM
dmaza added a comment.Jul 24 2019, 3:23 PM

Assuming $wgEnableSpecialMute = true. Neither $wgEnableUserEmailBlacklist nor $wgEchoPerUserBlacklist has to be true, which means you can see this link even if there is nothing you can do with it. I don't know why you would configure your wiki like this, though.

@dmaza I don't think we should show the link if the page is going to throw an error anyways. It's effectively an access denied (and perhaps we could use that mechanism?).

It shows an error message saying "Mute features are unavailable. This might be because: you haven't confirmed your email address or the wiki administrator has disabled email features and/or email blacklist for this wiki. "
We could check for $wgEnableUserEmailBlacklist but we can't check for $wgEchoPerUserBlacklist. I don't think there is anything we can do really other than what's already in place.

Regarding muting yourself, that's currently allowed on SpecialPreferences and there are no side effects afaik

I don't think there is anything we can do really other than what's already in place.

I don't see why we couldn't have an access check / hook so the link isn't displayed? I think special pages already have this mechanism?

It looks like SpecialPage::userCanExecute() can be overridden to determine if the user has "access". You can get the subpage with $this->par. I can move this to a new ticket if you'd like.

dmaza added a comment.Jul 24 2019, 7:44 PM

Sure, lets have another task and we can investigate there