Page MenuHomePhabricator

Use jQuery.suggestions to add reason suggestions to block/delete/protect forms
Open, Needs TriagePublic

Description

I think the sysops may benefit from having live suggestions while they type the reason for protecting/deleting/blocking.

The script at w:pt:MediaWiki:Gadget-SysopSuggestions.js provides this feature. It takes the values from

  • [[MediaWiki:Protect-dropdown]]
  • [[MediaWiki:Revdelete-reason-dropdown]]
  • [[MediaWiki:Filedelete-reason-dropdown]]
  • [[MediaWiki:Ipbreason-dropdown]]
  • [[MediaWiki:Deletereason-dropdown]]

which are already available in the form and then filter the list to display only those items which match what the user has typed.

Please consider including something similar to MediaWiki.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:00 AM
bzimport set Reference to bz32950.
bzimport added a subscriber: Unknown Object (MLST).

resources/src/jquery/jquery.suggestions.js exists; implementation hints could be seen in

  • ./resources/src/mediawiki/mediawiki.userSuggest.js
  • ./resources/src/mediawiki/mediawiki.searchSuggest.js
  • ./resources/src/mediawiki.widgets/mw.widgets.TitleInputWidget.js and ./includes/widget/TitleInputWidget.php

Change 330447 had a related patch set uploaded (by Filip):
Added reason suggestion in block/delete/protect forms

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

Change 330447 merged by jenkins-bot:
Added reason suggestion in block/delete/protect forms

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

Nick raised the priority of this task from Low to Unbreak Now!.Jan 20 2017, 4:33 PM
Nick added a subscriber: Nick.

Please revert this - we already have a perfectly good drop down list of 'canned' block (and deletion) log entries. The un-necessary duplication, particularly when deployed in this manner, has meant I no longer have the 'custom' log entries saved in my browser history which I can use to provide supplementary detail in addition to the drop down log entries.

As an example, when blocking socks of a user, I would choose the drop down block reason "Abusing multiple accounts" but in the text entry reason field, I would then add the username of the master account, thus giving a block entry which states "Abusing multiple accounts: [[User:Example]]" which is quick and easy, and really helpful to my fellow administrators if we're doing [[WP:DENY]] and won't be placing a sockpuppet tag on the user page.

If I delete pages they've created, I'll use the canned edit summary "G5: Creation by a blocked or banned user in violation of block or ban" but again, in the text entry reason field, I'll add "created by sockpuppet of [[User:Example]]" to give a full log entry of "G5: Creation by a blocked or banned user in violation of block or ban: created by sockpuppet of [[User:Example]]"

The provision of the existing 'canned' edit summaries is making writing custom log entries a little cumbersome too, as you type it changes the suggested text, and a couple of the suggestions are things like "<div class="notice" style="background:#def; border:1px solid #468; padding:0.5em; margin:0.5em auto; min-height:50px">[[File:Information.svg|left|50px|alt=|link=]]Welcome to Wikipedia. Because we have a [[Wikipedia:Username policy#Promotional names|policy" which is not helpful.

MusikAnimal lowered the priority of this task from Unbreak Now! to High.Jan 20 2017, 5:15 PM

Agreed. This implementation was a bit of a misfire, as it impacted the workflow of many admins. Please roll this back while we discuss how this could be better implemented, possibly by making it optional with a toggle in preferences, defaulting to off.

@BU_Rob13: Yeah, you're right. Will upload patch for this tomorrow. Setting in option is the best idea for now.

In T34950#2956507, @FilipGCI wrote:

@BU_Rob13: Yeah, you're right. Will upload patch for this tomorrow. Setting in option is the best idea for now.

New user preferences are discouraged, and this one probably doesn't warrant it.

This should have been reviewed with more care by more people. I don't think the change is particularly bad, but it could have been better though. Having both the dropdown and the suggestions visible at the same time is a bit strange, but having the list of all available options visible is good for new admins to see a list of common summaries to choose (while choosing one of the predefined ones isn't required, it gives consistency across the wiki).

Ok, this is my fault :( I have looked at the form only, but it seems I haven't recognized the separate reasons dropdown box :/ The current implementation is technically good, however, it looks a bit duplicated to the dropdown.

Florian lowered the priority of this task from High to Medium.Jan 21 2017, 6:58 PM

Btw.: Lowering the priority, as it, in fact, does not break the software :) See https://www.mediawiki.org/wiki/Phabricator/Help#Setting_task_priority

Btw 2: No clue, why gerrit-bot hasn't announced it here, but I created revert of the implementation in: https://gerrit.wikimedia.org/r/#/c/333360/

Mentioned in SAL (#wikimedia-operations) [2017-01-21T20:00:32Z] <legoktm@tin> Synchronized php-1.29.0-wmf.8/includes: Revert "Added reason suggestion in block/delete/protect forms" (1/2) - T34950 (duration: 01m 31s)

Mentioned in SAL (#wikimedia-operations) [2017-01-21T20:01:30Z] <legoktm@tin> Synchronized php-1.29.0-wmf.8/resources: Revert "Added reason suggestion in block/delete/protect forms" (1/2) - T34950 (duration: 00m 39s)

I deployed the revert, so it should be back to the status quo. I'll leave this task open for someone else to figure out whether we should be re-attempting this and how to address the concerns.

Thanks for doing this so quickly. I'd have no complaints if it's redeployed with a way to switch this feature off and on.

Change 340168 had a related patch set uploaded (by Filip; owner: Filip):
Converted alerts, and confirms to OOJSUI

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

Ammarpad raised the priority of this task from Medium to Needs Triage.Apr 29 2020, 9:52 AM
Ammarpad added a subscriber: Ammarpad.

Maybe the communities should be asked again, if there's no more need for this, the task should be declined.

Aklapper added a subscriber: Filip.

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)