The way it is currently implemented, the child order is not a property of the parent page. It's a property of the "space" (hierarchy subtree) containing the child pages. This comes from the fact that in XWiki the page hierarchy can have holes, i.e. you can have child pages whose parent page doesn't exist. Thus, you should be able to order child pages even if the parent page doesn't exist... The consequence is that the child order is not saved in the parent page but in a preferences page that configures the "space" (hierarchy subtree), even when the actual parent page is missing. So it's not enough to have edit right on the parent page because the child order is not saved there.
Storing the child order in the parent page is not trivial:
First, you need the parent page to exist.
Then we have to expose this feature outside the page administration, so we need a UI proposal for this (ping Thiago Krieck).
Then we either need a migration from the previous storage or keep the old storage as an override (i.e. allow space admin to overwrite the order defined by parent page editors). I fear the latter will confuse many users: you need to either disable the feature for page editors when a space admin order is in place, or keep it but don't allow saving and show a message to explain the situation... or allow saving but notify the page editor that the order won't be taken into account.
Finally, you lose the child order when you delete, move or rename the parent page without affecting the child pages.
And, this is an important change that needs to be voted on the forum. On my side I'm not convinced.
Marius Dumitru Florea on 18/Oct/24 11:09
The way it is currently implemented, {*}the child order is not a property of the parent page{*}. It's a property of the "space" (hierarchy subtree) containing the child pages. This comes from the fact that in XWiki the page hierarchy can have * holes*, i.e. you can have child pages whose parent page doesn't exist. Thus, you should be able to order child pages even if the parent page doesn't exist... The consequence is that the child order is not saved in the parent page but in a preferences page that configures the "space" (hierarchy subtree), even when the actual parent page is missing. So it's not enough to have edit right on the parent page because the child order is not saved there.
Storing the child order in the parent page is not trivial:
* First, you need the parent page to exist. * Then we have to expose this feature outside the page administration, so we need a UI proposal for this (ping [~tkrieck]). * Then we either need a migration from the previous storage or keep the old storage as an override (i.e. allow space admin to overwrite the order defined by parent page editors). I fear the latter will confuse many users: you need to either disable the feature for page editors when a space admin order is in place, or keep it but don't allow saving and show a message to explain the situation... or allow saving but notify the page editor that the order won't be taken into account. * Finally, you lose the child order when you delete, move or rename the parent page without affecting the child pages. * And, this is an important change that needs to be voted on the forum. On my side I'm not convinced.
Marius Dumitru Florea on 18/Oct/24 11:10
The way it is currently implemented, {*}the child order is not a property of the parent page{*}. It's a property of the "space" (hierarchy subtree) containing the child pages. This comes from the fact that in XWiki the page hierarchy can have *holes*, i.e. you can have child pages whose parent page doesn't exist. Thus, you should be able to order those child pages even if the their parent page doesn't exist... The consequence is that the child order is not saved in the parent page but in a preferences page that configures the "space" (hierarchy subtree), even when the actual parent page is missing. So it's not enough to have edit right on the parent page because the child order is not saved there.
Storing the child order in the parent page is not trivial:
* First, you need the parent page to exist. * Then we have to expose this feature outside the page administration, so we need a UI proposal for this (ping [~tkrieck]). * Then we either need a migration from the previous storage or keep the old storage as an override (i.e. allow space admin to overwrite the order defined by parent page editors). I fear the latter will confuse many users: you need to either disable the feature for page editors when a space admin order is in place, or keep it but don't allow saving and show a message to explain the situation... or allow saving but notify the page editor that the order won't be taken into account. * Finally, you lose the child order when you delete, move or rename the parent page without affecting the child pages. * And, this is an important change that needs to be voted on the forum. On my side I'm not convinced.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
