Current behaviour:
If * lacks createpage rights, it is impossible to use the "hide registered users" option on Special:NewPages
However, if *, despite lacking createpage rights, is granted createtalk rights, anonymous users can still create (some) pages, and thus this filter would still be useful
Desired behaviour:
If * lacks both createpage and createtalk rights, the filter option isn't presented
Change 551328 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Improve removal of "hide registered users" option on Special:NewPages
Per https://www.mediawiki.org/wiki/Developers/Maintainers, no code stewards are assigned for "Special pages". Would Platform Engineering be willing to look at the provided patch?
Change 551328 merged by jenkins-bot:
[mediawiki/core@master] Improve removal of "hide registered users" option on Special:NewPages
Doesn't actually work - NewPagesPager also needs to be updated to not ignore the parameter
Change 558323 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] NewPagesPager: Fix "hide registered users" option
Change 558323 merged by jenkins-bot:
[mediawiki/core@master] Follow up 9ef34a2f1d0: fix NewPagesPager "hide registered users" option
Change 560427 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@REL1_34] Follow up 9ef34a2f1d0: fix NewPagesPager "hide registered users" option
Change 560427 merged by jenkins-bot:
[mediawiki/core@REL1_34] Follow up 9ef34a2f1d0: fix NewPagesPager "hide registered users" option
@DannyS712 as far as the change goes, available permissions can change at anytime, so this filter shouldn't appear or not appear based on the current permission mapping. The expected result should simply be that there are no results if there are no results - this keeps the behavior consistent across all instances.
I'm afraid I don't understand what you're saying - the previous behaviour was already based on current permission mapping (if * had createpage) and I just updated it. But, given that now both the special page and the pager have identical canAnonymousUsersCreatePages functions, maybe it should be moved to the permission manager as a common function?
What I'm saying is that when viewing Special:NewPages, the control that uses the "MediaWiki:Rcshowhideliu" label should always be present, it shouldn't be added and removed based on the current set of permissions on a project. It isn't a bad thing that clicking "hide registered users" would produce no results. The permissions of * could have just changed 1 second ago. Additionally, regardless of if the control is displaying on the page or not, the control should actually function if called - resulting in no results if there do not currently happen to be any.
Having it always function would mean that, even if * cannot create pages, the query run still tries to filter them out - $conds[] = ActorMigration::newMigration()->isAnon( $rcQuery['fields']['rc_user'] ). Adding this condition even it'll always be true probably worsens the query performance
It's non-default, and only run if someone actually tries to run it, but would mean that the page is always consistently laid out (as far as displaying it). As far as should a query that someone is specifically asking to be run - be run why not? Do we really need a shortcut (that as noted isn't going to always be accurate) to bypass this? We don't put what-if-shortcuts on the rest of the controls there. (e.g. If a project removed the bot permission, or auto\patrol permission from all groups - we don't check for that and hide those links)
If you want to request that the filter always be allowed, please file a new task (though I don't think its going to be accepted) but that is outside of the scope of this task