Change #1083172 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/CheckUser@master] Remove namespace and tag filtering from Special:GlobalContributions

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

@Urbanecm Do you agree that these filters should not exist at all? For example, it seems as though filtering by the Main namespace might be useful. Similarly with tags that the accessing user knows to be on multiple wikis.

In T378179#10263364, @Tchanders wrote:

@Urbanecm Do you agree that these filters should not exist at all? For example, it seems as though filtering by the Main namespace might be useful. Similarly with tags that the accessing user knows to be on multiple wikis.

For the initial version, yes, absolutely. I do agree there are ways to make the filters multi-wiki aware, but that feels like a fairly complex change (significantly more complex than disabling the filters). For example, how would we determine whether a tag is present at multiple wikis? What is "multiple"? With namespaces, there's the question of "same ID, different meaning", which is something a machine cannot determine reliably at all I'm afraid (so we'd be left with hardcoding). If you think it is actually easier to make the filters usable in cross-wiki context than removing them, that would be okay as well.

For namespaces, how about using $wgCanonicalNamespaceNames only (i.e. excluding $wgExtraNamespaces)?

In T378179#10263501, @Tchanders wrote:

For namespaces, how about using $wgCanonicalNamespaceNames only (i.e. excluding $wgExtraNamespaces)?

I don't understand how that would resolve either "namespaces vary across wikis" or "namespace IDs vary across wikis" issue. AFAICS, canonical namespaces include extension-defined namespaces. Not all extension-defined namespaces are in
the $wgCanonicalNamespaceNames global variable, but some are, for example:

[urbanecm@mwmaint2002 ~]$ mwscript shell.php cswikisource
DEPRECATION WARNING: Maintenance scripts are moving to Kubernetes. See
https://wikitech.wikimedia.org/wiki/Maintenance_scripts for the new process.
Maintenance hosts will be going away; please submit feedback promptly if
maintenance scripts on Kubernetes don't work for you. (T341553)
Psy Shell v0.12.3 (PHP 7.4.33 — cli) by Justin Hileman
> $wgCanonicalNamespaceNames
= [
    -2 => "Media",
    -1 => "Special",
    0 => "",
    1 => "Talk",
    2 => "User",
    3 => "User_talk",
    4 => "Project",
    5 => "Project_talk",
    6 => "File",
    7 => "File_talk",
    8 => "MediaWiki",
    9 => "MediaWiki_talk",
    10 => "Template",
    11 => "Template_talk",
    12 => "Help",
    13 => "Help_talk",
    14 => "Category",
    15 => "Category_talk",
    250 => "Stránka",
    251 => "Diskuse_ke_stránce",
    252 => "Index",
    253 => "Diskuse_k_indexu",
  ]

> ^D

   INFO  Ctrl+D.

[urbanecm@mwmaint2002 ~]$

In this output, namespaces 250-253 belong to ProofreadPage, and only exist at Wikisources. Specifically with ProofreadPage, namespaces defined by this extension have different IDs at different wikis. For example, the same four namespaces at sourceswiki are NS104-107. This happens to avoid conflict of namespace IDs on per-wiki basis.

In addition to this, canonical namespaces should be probably retrieved via NamespaceInfo::getCanonicalNamespaces() rather than via the global variable, and that method returns all extension-defined namespaces. Those do not need to be present at all wikis and, as illustrated above, the ID of those can vary between wikis as well.

What would presumably be safe is restricting to core-defined namespaces only, as those should exist at any MediaWiki instance, and should have a shared meaning. This can apparently be requested via NamespaceInfo::getCommonNamespaces() (or NamespaceInfo::CANONICAL_NAMES to also include the names, but that has the @internal annotation, so probably not a good idea).

What would presumably be safe is restricting to core-defined namespaces only, as those should exist at any MediaWiki instance, and should have a shared meaning. This can apparently be requested via NamespaceInfo::getCommonNamespaces() (or NamespaceInfo::CANONICAL_NAMES to also include the names, but that has the @internal annotation, so probably not a good idea).

I think this is worth pursuing, rather than disabling the namespace filter.

It looks as though tags has a similar concept of commonly-available tags, with ChangeTagsStore::getSoftwareTags. These can be disabled in site config, but it might still be worth having the filter, perhaps with some help text.

In T378179#10265324, @Tchanders wrote:

What would presumably be safe is restricting to core-defined namespaces only, as those should exist at any MediaWiki instance, and should have a shared meaning. This can apparently be requested via NamespaceInfo::getCommonNamespaces() (or NamespaceInfo::CANONICAL_NAMES to also include the names, but that has the @internal annotation, so probably not a good idea).

I think this is worth pursuing, rather than disabling the namespace filter.

I would be in favor of removing the namespace filter. This isn't something present on https://guc.toolforge.org/ and from my data point of one user interview, the Steward we spoke said (IIRC) that they wouldn't use the namespace or tag filter (cc @KColeman-WMF who may remember the feedback on that as well).

In T378179#10268863, @kostajh wrote:

In T378179#10265324, @Tchanders wrote:

What would presumably be safe is restricting to core-defined namespaces only, as those should exist at any MediaWiki instance, and should have a shared meaning. This can apparently be requested via NamespaceInfo::getCommonNamespaces() (or NamespaceInfo::CANONICAL_NAMES to also include the names, but that has the @internal annotation, so probably not a good idea).

I think this is worth pursuing, rather than disabling the namespace filter.

I would be in favor of removing the namespace filter. This isn't something present on https://guc.toolforge.org/ and from my data point of one user interview, the Steward we spoke said (IIRC) that they wouldn't use the namespace or tag filter (cc @KColeman-WMF who may remember the feedback on that as well).

According to the user testing summary namespace is considered a helpful filter (although not heavily used). Specifically, it is used by some to reduce collateral damage from a block. It's included on Global Contributions because it currently exists in Xtools GUC and we are aiming for feature parity. During testing, users liked having it as an option but wanted to understand how it would work, which is why the design links to the standard namespaces list in the description text.

Change #1084130 had a related patch set uploaded (by STran; author: STran):

[mediawiki/core@master] [WIP] Support 'include' parameter in namespace select inputs

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

Change #1084131 had a related patch set uploaded (by STran; author: STran):

[mediawiki/core@master] [WIP] Support child class modifications of getForm field options

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

Thanks for the extra context and information everyone! Given the reasons from @KColeman-WMF, I also think it makes sense to keep these filters and restrict them instead of removing them outright. The functions already exist as well so I don't think it's too much of a stretch, implementation wise, and I've pushed up some proof of concept work for it. I'll go ahead and update the task to reflect this direction as well (and we can always change our mind).

Change #1084130 merged by jenkins-bot:

[mediawiki/core@master] Support 'include' parameter in namespace select inputs

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

Change #1084131 merged by jenkins-bot:

[mediawiki/core@master] Support child class modifications of getForm field options

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

Change #1083172 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Exclude non-common namespaces from the namespace filter

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

The namespaces listed are:

all
(Main)
Talk
User
User talk
Mediawiki
Mediawiki talk
File
File talk
MediaWiki
MediaWiki talk
Template
Template talk
Help
Help talk
Category
Category talk

Which matches NamespaceInfo::CANONICAL_NAMES (except for Special and Media, which should be ignored).

Test environment: local docker CheckUser 2.5 (bc8f729) 07:35, 1 November 2024.

In T378179#10279507, @gerritbot wrote:

Change #1084130 merged by jenkins-bot:

[mediawiki/core@master] Support 'include' parameter in namespace select inputs

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

I find after this change that other Namespace select components are empty. For example, on Special:AllPages. I have raised T378810.