Proposal: Redesigning the Rights Screen for Improved Usability

[tkrieck]

Hi all,

I’m sharing a proposal to improve the usability of the Rights screen in XWiki. This work is an intermediate step toward the broader full rights revamp currently being driven by the Required Rights proposal.

This is somewhat late and outstanding from my June roadmap as it came from a discussion with @MichaelHamann in May, sorry about that.

Context

The current Rights screen displays all users OR groups (so, not both), and permissions in a single table. While this provides full visibility, it becomes unwieldy and error-prone as the number of entities increases. The interface doesn’t scale well for large instances and is difficult to use on mobile or touch-based devices.

Proposal

I propose replacing the current Rights screen with a simplified and safer interface based on the following principles:

• A dedicated “Add Right” action for assigning permissions.
• A unified LiveData table listing both users and groups with their currently assigned rights.
• Table checkboxes that are read-only, preventing accidental edits from clicks or touches.
• Designed for mobile compatibility using LiveData.

This read-only overview prevents unintentional changes and allows admins to audit existing rights at a glance.

The general layout was also changed a bit by introducing titles for the two sections, the rights themselves and the checkboxes under them.

Managing Rights

Selecting a row or clicking the “Add Right” button opens a Manage Right dialog. This is the only place where changes can be made.

Key points:

• Rights are modified in this dialog, including deletion.
• For editing existing rows, the fields Type (user/group) and Name are locked to avoid breaking references or conflicting entries.
• Empty rights can be selected to unset permissions (pictured below).

Custom Rights

Custom rights will be displayed below the standard XWiki rights in the same interface, maintaining consistency and visibility.

Objective

As stated earlier, this is a stepping stone. My intent with this proposal is to reduce complexity and minimize possible user errors with the current implementation.

As always, I’d appreciate your feedback.
Thanks.

[vmassol]

Thx for the proposal.

@tkrieck

A dedicated “Add Right” action for assigning permissions.

I don’t understand the “Add Right” button. BTW I think it should be “Add Rights” (plural) since the dialog adds/modifies a set of rights (and not just one).

What does “Add” mean? We can only Set rights in this UI (and not Add anything).

Also you said that clicking on a row in the table would open the dialog to set the rights, so I don’t understand the need for that “Add Rights” button.

I’m not sure it’s clear that a row has to be selected to modify it.

@tkrieck

Rights are modified in this dialog, including deletion.

What does “deleting rights”’ mean? Rights can only be set (Allow or Deny) or not set.

@tkrieck

Custom rights will be displayed below the standard XWiki rights in the same interface, maintaining consistency and visibility.

What is a custom right? is it a right brought by an extension (and that we ideally need to add to the rights LD but we’re pushing that to later)?

Thx!

[MichaelHamann]

@vmassol

I don’t understand the “Add Right” button. BTW I think it should be “Add Rights” (plural) since the dialog adds/modifies a set of rights (and not just one).

What does “Add” mean? We can only Set rights in this UI (and not Add anything).

“Add Right” might be misleading, the idea is to add a user or group to the table. From what I understand/what I proposed, the idea is that we would only display users and groups in the table that have any rights set (granted or denied) but not all users. This is because one of the biggest usability problems of the rights UI is that its impossible to find the users or groups that actually have rights set when you have more than a couple of users and groups.

@vmassol

What does “deleting rights”’ mean? Rights can only be set (Allow or Deny) or not set.

You unset all rights for that user/group, and thereby remove the line from the table (and delete the XObject that grants/denies the rights from the document). Maybe “delete” isn’t that easy to understand, maybe it should be “unset all”?

In general, I like the proposal. What’s not so clear to me is the integration of extension rights (I assume that’s what “custom rights” are). At the moment, we have three places where we set rights:

1. The “standard” rights.
2. The extension rights.
3. Wiki admin right.

They all re-use the same UI. I think it makes sense to combine them, but it’s not clear to me how this would look like in the table.

Also, I have one more suggestion:

Technically, it wouldn’t be difficult to compute a user’s or group’s current actual rights, i.e. whether or not a user/group has a particular right. This could be particularly interesting for not-set rights, but also for set rights (for example, a right could be explicitly denied to an admin user, but the admin might still have it). Could we integrate this into the proposal somehow, both for the table and also for the popup (so you could first see which rights a user/group currently has before setting rights or also to check if the configured rights have the desired effect)? If possible, it would be nice if this could be an optional part of the proposal that we might implement or not, depending on the available time, or maybe also as a second step.

Regarding future directions, as @tkrieck didn’t mention that, what I mentioned to @tkrieck is that I would like to go towards:

1. Allow performing arbitrary changes before saving (setting/removing rights for any number of users/groups before saving).
2. Preview effective rights before saving (this would be technically challenging but not impossible I think, but definitely not something I would include in a first version).

These features would bring two main advantages:

1. We could better warn the admin when the admin is about to remove the admin’s own possibility to manage the rights of the page, even if that’s through granting a right to another user/group (we currently only warn when the admin modifies rights of groups the admin is part of).
2. The admin could perform bigger changes, like change how rights are managed in general without having to carefully think how to perform the changes such that all intermediate states are safe. Further, the admin could also preview if the result is what the admin wanted.

Another idea we could explore is to display in a space also the rights for parent spaces/the wiki, in read-only mode if the user cannot modify them or even editable when the user has the right to modify them. That way an admin could have a global view which rights apply to the current page/space and could maybe even modify the rights on the whole hierarchy, possibly even with a preview of the whole hierarchy.

The idea of showing the whole hierarchy (without direct edit or preview of unsaved changes, just with a link to the respective admin area) also wouldn’t be too difficult I think, so we could also plan this for earlier versions.

Note that seeing all defined rights that affect a page is a frequently requested feature, we even have an extension for it and seeing all rights set on the whole wiki is an important feature of the admin tools application.

[tkrieck]

@vmassol

I don’t understand the “Add Right” button. BTW I think it should be “Add Rights” (plural) since the dialog adds/modifies a set of rights (and not just one).

I see what you mean and perhaps “Add Right” was not the ideal label. I wanted to communicate that something will be added to the Rights table. Maybe “Assign Rights” is better, or something along this line.

@vmassol

What does “deleting rights”’ mean? Rights can only be set (Allow or Deny) or not set.

The same as above, if we’ll have Assign Rights for example we’ll need “Unassign Rights” OR “Remove Rights”.

@vmassol

What is a custom right? is it a right brought by an extension

It is, yes. I’ll rephrase it on the proposal.

[Simpel]

I do appreciate the ideas of @tkrieck and @MichaelHamann. Luckily we have only few groups and special rights set today.

[MichaelHamann]

@tkrieck What’s the status on this? Are you waiting for any feedback?

I’ve already mentioned this to @tkrieck but I want to add it here to make sure that it’s not forgotten: I think we should not only list rights of existing users and groups but also rights of users and groups that don’t exist. While have a listener that removes rights when a user or group is deleted, this situation can (and does) easily happen with Confluence imports (for example, when only content and rights are imported because users log in with SSO). Currently, such rights aren’t displayed and thus cannot be removed in the UI, but are taken into account. When a right object grants view right to a non-existing user, nobody else (apart from admins of course) will have view right. The UI needs to display all rights that are taken into account, regardless if the user or group exists or not.

[tkrieck]

@MichaelHamann

@tkrieck What’s the status on this? Are you waiting for any feedback?

Not really, I addressed some feedback in a previous comment and updated the proposal page right now with new images and updated definitions.

IMO the visual design can be closed, unless someone disagrees. If it’s ok for you, I’ll leave this thread open a day more and then mark it as closed.

[MichaelHamann]

@tkrieck

IMO the visual design can be closed, unless someone disagrees. If it’s ok for you, I’ll leave this thread open a day more and then mark it as closed.

It’s not clear yet to me how extension rights are handled in the table. You’re proposing that we remove the extra “extension rights” table and integrate them all in one table? What about the wiki creation right, should this also be integrated?

[vmassol]

Yep I had the same questkon as @MichaelHamann since your view UIs above only shows the core rights and is thus not scalable horizontally… Technically it’s also a bit more complex since it means introducing some UIXP(s).

FYI @tkrieck on xwiki.org we have these extension rights:

[MichaelHamann]

@vmassol

Technically it’s also a bit more complex since it means introducing some UIXP(s).

I don’t think we would need UIXP(s) for that, we can already enumerate all rights including extension rights - otherwise we also wouldn’t be able to build that extension rights UI. I haven’t looked at the actual code, but I’m quite certain that this is just a UI issue, not a technical issue.

[vmassol]

Indeed you’re right, I spoke too fast.

[surli]

Thanks for the proposal @tkrieck I do like the idea of the separation between a read-only table and a form for editing rights.

Just a question about your proposal though: have you checked how to handle displaying rights in case of subwiki when we display local and/or global users? Currently we have this kind of things:

as you can see it’s adding a new layer of complexity… I guess we could add a filter in the LD maybe? But there could be better options maybe?

[tkrieck]

@MichaelHamann

You’re proposing that we remove the extra “extension rights” table and integrate them all in one table?

@vmassol

Yep I had the same questkon as @MichaelHamann since your view UIs above only shows the core rights and is thus not scalable horizontally…

Yes, that’s my initial proposal. I noticed now that in my image of the table these rights are not shown though, I added some below.

This table can grow big of course, that’s why it would be important to try to fix the starting columns in the scrolling somehow. Also pictured below.

@surli

Just a question about your proposal though: have you checked how to handle displaying rights in case of subwiki when we display local and/or global users?

Hmm, that’s a new thing for me, for sure. Do you think this feature has a lot of use? If yes, I would add an option before the table for this. Something like “Show Rights for this Wiki only”.

[surli]

@tkrieck

@surli

Just a question about your proposal though: have you checked how to handle displaying rights in case of subwiki when we display local and/or global users?

Hmm, that’s a new thing for me, for sure. Do you think this feature has a lot of use? If yes, I would add an option before the table for this. Something like “Show Rights for this Wiki only”.

Yes it’s important for admin of subwikis to be able to set rights for both local and global users: note that the form where the right are edited should also reflect that.

Now for me the question is more how to show them: I’ve the feeling that most of the time we should display both global/local users & groups. But probably some kind of filtering would be helpful, that’s why I proposed a new column for making the distinction, allowing to filter / order.

[vmassol]

@tkrieck

Yes, that’s my initial proposal. I noticed now that in my image of the table these rights are not shown though, I added some below.

Then I don’t think I like it that much as the scrolling makes it a bit unusable IMO (I’m pretty sure some users will miss it).

@tkrieck

This table can grow big of course, that’s why it would be important to try to fix the starting columns in the scrolling somehow.

I don’t understand why you’re referring to starting columns. The issue for me is the number of rights that doesn’t lend itself to be displayed as columns.

This is why Caty had proposed something like this back then: https://design.xwiki.org/xwiki/bin/view/Improvements/RightsProposal

[tkrieck]

@surli

Yes it’s important for admin of subwikis to be able to set rights for both local and global users: note that the form where the right are edited should also reflect that.

Thanks for the input I’ll rework the proposal to also feature that.

@vmassol

I don’t understand why you’re referring to starting columns. The issue for me is the number of rights that doesn’t lend itself to be displayed as columns.

When the user is scrolling is easy to miss context of the Rights on columns if they don’t see to what user/group each row belongs to. I propose them to be fixed so this context is maintained at the expense of viewport space.

@vmassol

This is why Caty had proposed something like this back then: https://design.xwiki.org/xwiki/bin/view/Improvements/RightsProposal

Interesting proposal, but it’s from 2013, do you know why the Rights UI was never developed like that? I see some interesting points, like the advanced mode which turns Rights columns into lines and filters for global and local rights. But I also think this is a much more in depth rework of the interface, my proposal here is simpler on purpose, so it can get implemented quicker.

[vmassol]

@tkrieck

do you know why the Rights UI was never developed like that? I see some interesting points, like the advanced mode which turns Rights columns into lines and filters for global and local rights. But I also think this is a much more in depth rework of the interface, my proposal here is simpler on purpose, so it can get implemented quicker.

It was put several times in the roadmap (or we wanted to, don’t recall exactly) but every time there has been something more urgent to do. And yes you’re right, it’s a big refactoring and that’s one reason it got postponed.

Note that my point above was not to implement Caty’s proposal (there’s a lot more than just the way to display the rights), but just to show an idea of how the rights could be displayed to fit in the viewport, or have a way to access a specific right config where there are lots of them (AFAIR, we support 64 rights in total).

[surli]

@tkrieck

I like the idea of having a scrolling bar only for the rights, and it’s probably the simplest solution without going into a full refactoring. Now I’m also a bit afraid about the discoverability of this scrolling bar, especially if there’s a lot of users/group and your screen doesn’t display the bottom of the table. I don’t know how we could display a visual hint for the user?

[tkrieck]

@surli

I don’t know how we could display a visual hint for the user?

Good point, some visual indication of more columns would be welcome. Of course, the user can always click a row to see the full set of Rights if they suspect something is off.

[vmassol]

@tkrieck

Of course, the user can always click a row to see the full set of Rights if they suspect something is off.

How do they discover this BTW? Is there a visual cue when you hover over a row?

Thx