When a non-admin user copies, moves or deletes a nested page they created, the preferences of that page (that may have been set by an admin user) are left behind, i.e. are not copied, moved or deleted along with the parent page. This can create a lot of confusion. See Loading... for some explanation of the current behavior.
One option to fix this is to handle WebPreferences pages in a special way in the refactoring jobs (copy, move, delete):
perform the delete if the parent page is also deleted in the same job and the user that triggered the job has the right to delete the parent
perform the creation if the parent page is also created in the same job and the user that triggered the job has the right to create the parent
Do you see other options? Do you agree that the page preferences should be copied / moved / deleted along with the parent page?
+1 from me to handle it at the same time as its parent page. I don’t see a use case where the user would want to leave the preference page behind and it makes things look more consistent.
In addition, we could add an info box at the top of the Page Administration template to inform the user about the purpose and special behaviours of this page. It would also make it a bit more visally distinct from the general administration page.
I agree in general that we should move preferences even when a non-admin user moves a page.
For me, the main question is what to do in the different scenarios. For example, what if a parent page is moved without children? Should the WebPreferences page be moved, nevertheless? What if a page is renamed as terminal page? Would then rights set on this page and its children be lost? Or shouldn’t we convert them to rights just set on the page if possible?
Could you explain why it doesn’t work currently? Is it because of some rights missing or simply the user didn’t move children pages too?
What happens in the use case where you have a nested page with several children pages and some of them are created by an admin user (or PR user), are they moved too or excluded? Using the same logic that you proposed, shouldn’t they also be moved?
I wouldn’t move the WebPreferences page in this case because it holds preferences affecting the child pages as well. Basically the child pages would lose those preferences. But we could copy it, so that both the moved parent page and the now-orphan child pages preserve their preferences.
I wouldn’t delete the WebPreferences in his case. I’d keep it in place, unchanged. It would be nice indeed to “copy” some of the preferences to the new terminal page, but I’m not sure if this kind of refactoring happens often enough to make it worth the effort.
The non-admin user doesn’t have the right to delete the child WebPreferences page. By default, the creator of a page has the right to delete that page. The problem is that the child WebPreferences page is not created by the non-admin user (they don’t have the right anyway) but by the admin user when they first access the Page Administration. It’s worth mentioning that this is not so much different than having another (non-admin) user create a child page: the creator of the parent page won’t have the right to move the child page. So moving pages by non-admin users has other limitations as well. I mean, I’m not sure what’s worse: losing the child order or losing some child pages.
The non-admin user can’t create the child WebPreferences page on the target location (for good reasons) because we are currently handling the preferences pages in a special way: checking for edit right translates into checking for admin right.
Those pages are currently excluded from the move (i.e. they are left behind) because the user that triggered the move doesn’t have the right to delete those pages from their current location.
Indeed, @tmortagne raised the same question. I don’t think we can handle the WebPreferences page as a regular child page. It would mean that delete right on a parent page implies delete right on any nested page, i.e. you won’t be able to restrict delete right at a lower level. This is a big (possibly breaking) change.
I think we’re biased by this implementation detail that page preferences are stored in a child page. If they were stored differently (e.g. as metadata on the page itself), then it would have probably made more sense to move the preferences along with the page.
I agree we should not delete it. But I feel the natural expectation would be for the behavior to be the same as for a regular copy (the same rights apply to the new location).
I’m wondering if from a UI point of view and if the user is an admin, we shouldn’t add a step or at least a hint in the UI when a refactoring operation is performed to “review administration in new space(s)”.
Also if we’re not sure about the right thing to do we could also provide a new interactive question for this.
I’m a bit bothered about that behaviour: right now, if as an admin you move a parent page without its children the WebPreferences is never moved or copied. So do you mean we should change that too?
move the WebPreferences if there are no child pages left behind
copy the WebPreferences if there are child pages left behind
Do you see any problems with that, functionally speaking? (putting the implementation detail aside, but I’m deducing from your reply that it’s not trivial…)
We already do that one if you’re admin as then you have admin right and then you already have the right.
But for:
that’s an entirely new behaviour: we never performed this operation, it’s not related to rights at all anymore.
So I’m wondering how disturbing it could be for an admin that suddenly when they move some pages they also copy their WebPreferences. It feels like we might need a configuration switch for that one.