This is a generic problem, affecting any preference set on a parent page (e.g. color theme, panels, access rights). Note that when the non-admin user moves the parent page they currently get this warning message at the end of the job:
Done but unexpected errors where logged during the process.
The job log contains an error like this:
You are not allowed to delete [Home » Playground » WebPreferences].
There are two problems:
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 only solution I can think of is to handle the 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
Marius Dumitru Florea on 27/Jan/25 16:17
This is a *generic* problem, affecting any *anypreference* set on a parent page (e.g. color theme, panels, access rights). Note that when the non-admin user moves the parent page they currently get this warning message at the end of the job:
{quote} Done but unexpected errors where logged during the process. {quote}
The job log contains an error like this:
{quote} You are not allowed to delete [Home » Playground » WebPreferences]. {quote}
There are two problems:
* 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. See https://github.com/xwiki/xwiki-platform/blob/0b145548b8c5eaa57f40242c7ea8a8c04b4f014b/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java#L572 .
The only solution I can think of is to handle the {{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
Marius Dumitru Florea on 27/Jan/25 16:18
This is a *generic* problem, affecting *any preference* set on a parent page (e.g. color theme, panels, access rights). Note that when the non-admin user moves the parent page they currently get this warning message at the end of the job:
{quote} Done but unexpected errors where logged during the process. {quote}
The job log contains an error like this:
{quote} You are not allowed to delete [Home » Playground » WebPreferences]. {quote}
There are two problems:
* 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. See https://github.com/xwiki/xwiki-platform/blob/0b145548b8c5eaa57f40242c7ea8a8c04b4f014b/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java#L572 .
The only solution I can think of is to handle the {{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
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
