Page MenuHomePhabricator

Move in intestactions doesn't pick up if the page is only covered by cascading protection
Open, LowPublic


I get that cascading protection is technically edit protection, but since it also prevents moving a page, I would expect intestactions=move to return correctly based on that status, much as intestactions=edit does, if it is only protected through transclusion on a cascade-protected page.

Event Timeline

Restricted Application added a project: Platform Engineering. · View Herald TranscriptNov 13 2020, 1:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Amorymeltzer I could not reproduce this - on all of the cascade protected pages I tried, the api correctly told me I couldn't move or edit the page. Can you please provide example steps to reproduce?

Amorymeltzer renamed this task from Move in intestactions doesn't pick up if the page is covered by cascading protection to Move in intestactions doesn't pick up if the page is only covered by cascading protection.Nov 13 2020, 2:15 PM
Amorymeltzer updated the task description. (Show Details)

@DannyS712 Sorry, I realize in my haste I wasn't fully clear: I meant a page protected only by virtue of being transcluded, not the page that is directly cascade protected. See, e.g.,

DannyS712 moved this task from Unsorted to Later on the User-DannyS712 board.

Okay, so now I can reproduce|move&formatversion=2 says I can move the page, but not edit
Using full details at|move&intestactionsdetail=full&formatversion=2 says nothing about move (meaning no permission errors), but has the cascading info for edit

Some debugging on the beta cluster suggests:
The reason for this is that, officially/technically, PermissionManager things that the user *can* move the page, because the PermissionManager checks for whether a user has the right to move a page are weaker than the MovePage checks that ensure that the user can also edit it.

The PermissionManager thinks that the user can move the page because there are no cascading move restrictions, because when restrictions are saved in the database, the cascade option is ignored for everything but edit. As far as I can tell, this has been the case since T14650: It should be possible to enter expiry dates for edit and move protection separately when 'pr_cascade' => $cascade ? 1 : 0 was switched to 'pr_cascade' => $cascade && $action == 'edit' ? 1 : 0 (See rMW807c3afaa73b: (bug 12650) Make it possible to enter separate expiry times for each…)

Does it make sense to set pr_cascade to 1 even for non-edit actions? Or should the api have special handling for moving to also check edits? Or is everything working as intended?

Why this needs special handling when Special:MovePage also does not take account of the cascade on inital view?

It is okay to expect the correct information because you want to test for move, but when the UI also allow to see that page, the api acts the same.
Api would reject on action=move while the UI would also reject on submit.

@Umherirrender Indeed — that'd be T27912, which, no joke, you opened exactly ten years ago!

@DannyS712 I image there's probably a larger bit of discussion/work to be had/done regarding cascading (see also: T265626). It's an old, weird thing, clearly, but "edit protection that applies to edit and move protection but only detectable as edit protection" is clearly incongruous.

AMooney triaged this task as Low priority.Nov 17 2020, 2:12 PM
AMooney moved this task from Inbox to Tracking/Watching on the Platform Engineering board.