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.
Description
Description
Related Objects
Related Objects
- 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…
Event Timeline
Comment Actions
@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?
Comment Actions
@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
Comment Actions
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?
Comment Actions
Why this needs special handling when Special:MovePage also does not take account of the cascade on inital view?
https://test.wikipedia.org/wiki/Special:MovePage/Page4242
https://test.wikipedia.org/wiki/Special:MovePage/User:Amorymeltzer/sandbox
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.
Comment Actions
@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.