Marius Dumitru Florea we don't need to update the storage in order to allow users with edit right to update it, we just need to make a custom API and a custom service for these operations (if they don't exist yet), that would use protected API to bypass the required admin right to save in WebPreferences, and check rights on its own (on the pinned pages API side), for the edit of the parent.
This means that the user with edit rights would only be able to update this through this API (only admins will be able to update this through the other APIs / UIs (object editor, rest api)), which is totally fine. What we need to provide is a UI / API to put in the hands of users, not a storage commitment.
From a logical point of view, this action is "tied" ("related") with the move, copy or create action: these are the actions where page tree placement is chosen today, and the order is part of this placement. Which brings us to the edit right on a tree of pages (page and children).
What I meant here when I said "logical point of view" is functional: this is how this feature is visible from the standpoint of a user.
Note that, unless I am missing something significant here, this could even be coded as an extension - the API can be written as an extension and the UI as an UIX. However, it would be a pity for this to be an "extra", as it is incomprehensible that the product doesn't have it by default.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
