Proposal: Redesigning the Rights Screen for Improved Usability

Development
,
1

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.

Screenshot 2025-07-01 at 10.44.58
Screenshot 2025-07-01 at 10.44.581024×271 34.3 KB

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.

Rights List
Rights List851×434 31.5 KB

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.

Rights Maintenance
Rights Maintenance343×517 23.2 KB

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).

right details

Custom Rights

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

custom rights (1)

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.

2

Thx for the proposal.

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.

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

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!

3

“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.

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.

5

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.

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

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

6

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