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.
- Mentioned Here
- T27912: show information about cascade protection on Special:MovePage
T265626: Protect API can allow (and display) an inaccurate move level alongside cascade protection
T14650: It should be possible to enter expiry dates for edit and move protection separately
rMW807c3afaa73b: (bug 12650) Make it possible to enter separate expiry times for each…
@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., https://test.wikipedia.org/w/api.php?action=query&format=json&prop=info&titles=Page4242&intestactions=edit%7Cmove
Okay, so now I can reproduce
https://test.wikipedia.org/w/api.php?action=query&prop=info&titles=Page4242&intestactions=edit|move&formatversion=2 says I can move the page, but not edit
Using full details at https://test.wikipedia.org/w/api.php?action=query&prop=info&titles=Page4242&intestactions=edit|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.
@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.