Allow non-admin users to pin child pages

Development
1

Hi everyone,

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.

WDYT?

Thanks,
Marius

2

Hi Marius,

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.

3

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?

4

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.

5

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.
1 Like
7

So, to get back on topic,

Of course, I agree that users with edit rights should be able to order pages, very much +1.

Honestly, I think this is an overkill. I’m not sure there are enough cases when restricting this more than the edit right is needed. From my pov, we don’t need an option here.

The rest of the implementation proposal seems correct, to me. Storage of the data and the rights that update it don’t need to be correlated (I agree that it’s easier for everyone if they are, but well, they are not).

As a side remark, what we need here is not a power user right, but the famous right to give rights. Then all the other settings of a page root (colors, panels, etc, pinned pages) make sense to be accessible to whoever had the right to create it in the first place (edit), and the only thing that would remain from the current page administration that would require more than edit would be the setting the rights. Today, the page administration is way way too restricted, and bound to admin, for legacy reasons, but it doesn’t really have an UX justification.

For top level pages we would still ask for wiki administration rights.

I can see how some users may complain, but well, first level is indeed a special case, we can assume that it’s ok to have to contact the admin if you want to change something at that level.

Thanks for handling this,
Anca

8

Hmmm indeed that’s something coming up often and it’s much well defined that this “power-user” right, and I guess in most of the cases it would solve the issue. :+1:

9

Indeed, the children order is not a property of the parent, but more of the family (the ensemble of page and children). For me, that ensemble is best defined today by the edit right on page and children, as it’s balanced enough (admin is putting the power too much on the parent side in the sense that you need someone with full, undeniable power on the parent to order the children).

10

Indeed, the REST resource and the children viewer UI extension would allow us to “hide” the implementation detail that the list of pinned child pages is stored in the page preferences (allowing us to change the storage more easily in the future).

Good question. If we add the UI extension point to the children viewer and inject there the Pinned Pages configuration UI then it doesn’t make sense to keep it also in the administration. It’s best to have a single place / way to pin child pages.

But if we introduce the “right to change rights” and open the Page Administration to page creators even if they don’t have this “right to change rights” then the Pinned Pages configuration can stay in the Page Administration. But this feels more complex to do. So for short term I’d move the Pinned Pages configuration UI from the Page Administration to the children viewer.

Good point. Indeed on the long term it would be better to open the Page Administration (maybe renamed to Page Configuration or Page Settings) to users that don’t have the right to change rights (basically the Access Rights section would be visible only to those that have the right to change rights).

Thanks,
Marius

1 Like