Page MenuHomePhabricator

Special:NewPages - allow hiding pages created by users when non-users can create talk pages
Closed, ResolvedPublic

Description

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

Event Timeline

Restricted Application added a project: User-DannyS712. · View Herald TranscriptNov 17 2019, 3:46 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

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

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

DannyS712 added a project: Core Platform Team.

Per https://www.mediawiki.org/wiki/Developers/Maintainers, no code stewards are assigned for "Special pages". Would Core Platform Team be willing to look at the provided patch?

Florian closed this task as Resolved.Nov 18 2019, 3:53 AM

Change 551328 merged by jenkins-bot:
[mediawiki/core@master] Improve removal of "hide registered users" option on Special:NewPages

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

DannyS712 reopened this task as Open.Dec 17 2019, 6:07 AM
DannyS712 moved this task from Merged to Awaiting review and deployment on the User-DannyS712 board.

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

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

Change 558323 merged by jenkins-bot:
[mediawiki/core@master] Follow up 9ef34a2f1d0: fix NewPagesPager "hide registered users" option

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

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

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

Change 560427 merged by jenkins-bot:
[mediawiki/core@REL1_34] Follow up 9ef34a2f1d0: fix NewPagesPager "hide registered users" option

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

@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.

@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.

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)

DannyS712 closed this task as Resolved.Jan 2 2020, 3:36 AM

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