We recently introduced the ability to pin (reorder) child pages, but you need to have:
wiki administration rights to be able to pin (reorder) top level pages
page administration rights to be able to pin (reorder) child pages
Some users have complained that requiring administration rights to pin child pages is very limiting. See Loading... . I tried to argue that the child order is not a property of the parent (so it’s not enough to have edit right on the parent) but it seems many users expect this:
if you can add something in the children of a page, why can’t you choose where to add it (order it)
The current limitation comes from the fact that the list of pinned child pages is stored in:
wiki preferences (XWiki.XWikiPreferences page) for top level pages
page preferences (WebPreferences page) for nested pages
and both require administration rights to edit. Changing the storage is not easy as we’ll have to handle the migration. Instead, I’m thinking that we could implement this:
add a page-level configuration option to control whether edit right on the parent page is enough to allow pinning child pages, true by default
implement a REST resource to update the list of pinned child pages, that checks access rights based on the configuration option mentioned before (i.e. edit or admin)
add a UI extension point to the Children viewer (?viewer=children), allowing extensions to inject additional “tabs” besides the default one that lists the child pages using a live data (it would look similar to the Page Index); the tabbed UI could be hidden if there is only one tab (the default live data view)
the Index Tree Application can then provide:
either a generic “Tree” tab that shows the subtree rooted in the parent page, and has a button to switch the tree into drag & drop mode where the user can pin child pages (basically replicate half of the Navigation Panel administration section); the button would only be shown when the configuration option allows pinning with only edit right
or a dedicated “Pinned” tab that replicates the Pinned Child Pages administration section (the suggest input and the Save button); this tab would be available only if the configuration allows pinning with only edit right
eitherway, the tab added by the Index Tree Application would use the REST resource to update the list of pinned child pages.
Obviously this would fix the limitation only for nested pages. For top level pages we would still ask for wiki administration rights.
my understanding of the problem is not that much that the migration is complex, but that even if we migrate we’d need to decide where to put the data and it probably wouldn’t be in an xobject so we’d need probably anyway the REST endpoint you’re mentioning and also the UI you’re mentioning
I guess your proposal also involve that Pinned Child Page administration section would disappear, or it would be duplicated between administration and children viewer?
I might be wrong but I’m afraid that users will quickly complain about that too… Maybe we could provide same UI in the index tree for the wiki?
I’m wondering if in the long run we shouldn’t start thinking about having another right in XWiki for such things, i.e. keep the administration right as it is, but add a “power user” right allowing cosmectic changes in the wiki, like ordering pages, changing style, maybe configuring some editor options. Maybe @tkrieck has an opinion on that.
From what I understand, this is different from our distinction between simple users and advanced users, right? Creating a ‘power-user’ right is another level on that?
Regarding reordering, this is something that stays in the level of the user? Meaning, my order of pages might be different from yours?
No I meant something entirely different, technically I was thinking about a new right, like you have “admin” right or “programming” right. You would be granted “power-user” right. It’s probably not best name but I don’t have many ideas here for that concept.
No what we’re discussing here is about an order that is persistent and applied for all users.
Ok, it makes more sense now. So this new Right would be something like a “sub-admin”. I like the idea, and make sense in the context of reordering the pages for everyone.
Something like this?:
Admin: Administer the whole wiki, more technical. Can create wikis, users, install extensions, etc
Sub-admin (gardener): administer the content of the wiki. Order of pages, look and feel changes, etc. But cannot do more destructive or big changes on the wiki.