| Samwalton9-WMF | |
| Oct 3 2024, 12:08 PM |
| F57695195: Screenshot_1.png | |
| Tue, Nov 12, 2:46 AM |
Users can currently restrict Nuke's page listing functionality to a specific namespace. Sometimes, however, users have a use case for listing all pages except those in a specific namespace, or pages in multiple specific namespaces (e.g. Talk and User Talk).
If we migrated from a single-option dropdown to a multi-select we could solve both use cases.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T375757 WE1.3.3: If we improve the user experience and features of the Nuke extension ... | |||
| In Progress | Chlod | T376379 Change namespace selection from a dropdown to a multi-select in Nuke |
! In T370974#10199244, @Blablubbs wrote:
- Allowing people to exclude namespaces (and/or list multiple namespaces of interest) as opposed to simply enabling them to limit queries to a single namespace
- This is likely to be useful because many nuke operations will likely want to exclude individual namespaces. This applies specifically to user talk pages, which -- on enwiki at least -- are almost never deleted. If, say, a block-evader created a bunch of main-, project- and templatespace pages that an admin wants to delete per CSD G5, but they first gamed extended-confirmed by mass-placing welcome messages on the talk pages of newly-registered users, then the current filtering setup would either require them to not filter by namespace and manually (un-)tick all user talk pages, or to run nuke several times -- once for each namespace of interest. Both approaches seem suboptimal from a UX perspective.
@Ottomata it looks like https://gerrit.wikimedia.org/r/c/operations/puppet/+/376395 is attached to the wrong Phab ticket number :)
Another approach here could be to have a namespace multi-select, like on RecentChanges.
@Ottomata it looks like https://gerrit.wikimedia.org/r/c/operations/puppet/+/376395 is attached to the wrong Phab ticket number :)
Wow, indeed. It was waiting for 7 years to be attached to this ticket!
Change #1088704 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):
[mediawiki/extensions/Nuke@master] Make namespace selector multiselect
This probably needs a hook signature change. $namespaces will become an array of integers containing all the namespaces the user selected after this, so it wouldn't be compatible with the current NukeGetNewPages hook (which only takes int|null for $namespace). What I'm wondering is how we'll be able to pass down the array safely without breaking existing uses, while the old signature goes through deprecation.
1088704 is pretty much ready for review, but I've set it to WIP for now while we think about this. For now, backwards compatibility is maintained in the patch by setting $namespace to null if multiple namespaces were selected.
n.b. The no-JavaScript experience for this kind of sucks. The user will get a multiline text box, and will have to enter namespace IDs per line. It's possible to accept namespace names (e.g. "Talk", "Project", "Help") here, but it will add some complexity to processing the list of requested namespaces since we have to process that on our own. I have that patchset ready, in case it's something we'd like to retain support for.
Accepting namespace names sounds like a localisation nightmare, so numbers seems the better approach. I've asked internally if there's any way for us to pull data on how many users even use Nuke with JS disabled.
It's definitely possible, taking into consideration localization. The localized names for every namespace is already provided to us by the Language service, and the English (canonical) names by NamespaceInfo. The complicated part is harmonizing the data, since they both don't offer a "namespace name to namespace ID" mapping that could easily be merged in the same array (NamespaceInfo::getCanonicalNamespaces provides names in id => name format, where name is capitalized; Language::getNamespaceIds provides names in name => id format, where name is lowercase). From user input to namespace IDs is 50 lines, but I understand if it's not really worth the extra effort if no one's going to use it anyway.
@Chlod Maybe we go forward with the basic solution (entering integers) for now, and then I'll see about pulling this no-js data and we can evaluate if it's worth complicating things for the other flow.
Got it. That just leaves what to do with the hook. I'll try to ask around on what to do about that soon.
Yes, we would have to modify the hook in Flow so it doesn't break functionality there. Per the editing team, it looks to be a one-line change, and Nuke on Flow only deletes new topics, not comments.
We also discussed considering running the hook once for each selected namespace as possibility to maintain compatibility with the existing hook interface. Potentially we could just not expose that larger data structure.
Otherwise, just creating a new hook with a similar name while deprecating the existing hook would be preferable.
Noting here that we've decided to go with this approach for now. This avoids having to make changes to Flow, and also allows us to refine public interfaces later on down the line when we've completed other parts of the Nuke project. I'll send the patch to Eng. review when it's ready.
I spoke with @MNeisler today and she re-ran the analysis written to retrieve T240697#7127421, but limited to administrators. We found a percentage of 22%, though the same analysis yielded 17% for all users, which is substantially higher than the 5% found previously, so there's some followup analysis to do there to verify these numbers.
If the no-JS percentage is that high, then perhaps we should still accept namespace names. There is a way to do this, though I've left that solution un-uploaded since it didn't look like no-JavaScript users were that much at the time. But given the info we know now, perhaps it's worth adding support for that now.