Required Rights administration location

Development
#1

Hello all,

I’d like to have your opinion regarding the location of required rights administration page, and the way to access it from a given page.

Note: This is a sub-discussion in the context of Document Rights Management Improvement, focused on the required rights administration.

Option 1: Integrated in the rights UI

Path for users with admin rights on non-terminal pages:

  • image
  • image
    Path for (advanced) users without admin rights or on terminal pages:
  • image

image

Option 2: Provide a dedicated menu entry and page

Menu entry, displayed only to advanced users with script or programming right for the current page
image

This menu entry would lead to a administration page similar to the one presented for option 1

I am currently in favor of Option 1 as users are already familiar with the current rights administration UIs and expected to see other rights related forms in the same place. Also, Option 2 requires to introduce a new entry in an already crowded menu

WDYT?

Document Rights Management Improvement
#2

+1 for Option 1

Option 2 introduces some language that is specific to the implementation, in an anchor: from a user perspective, AFAIK it would not be immediately clear what the “Required rights” clickable does.
See this result on the google ngram viewer. The stats on google trends are similar.

I think using this name in non interactive parts of the interface would be less of a problem because a new user doesn’t “need” to understand/remember the name to use the functionality optimally.

#3

I’m a bit mixed: I agree with the path for advanced users or on terminal pages through the “Access rights” menu. I also agree with the access through the “Administer Page”. Now on this UI I would provide a new menu entry below Extension rights for Required rights to make it easy to find.

#4

That also a valid option, maybe even slightly easier to implement.
Pro: things are cleanly separated
Cons: the user does not have in the same view the rights of the page and the required rights (but users don’t have inherited rights in view when manipulating page rights anyway).

#5

+1 for Option 1 with @surli’s dedicated “Required rights” admin entry variation

#6

+1 for the Admin Rights UI location + the new Required Rights menu entry under Users & Rights

#7

Actually, I found a limitation that we need to consider before going for the option proposed by @surli

The page administration (see screenshot below) is only accessible to Admin users. Meaning that only admins would be able to activate and configure RRs.
image

But, imo users with script or programming rights should be able to activate RRs, and activate the rights they have.

  • Alternative 1: we accept the limitation and users without Admin rights will need to request an admin for help first (which imo is quite blocker)
  • Alternative 2: we move back to the original Option 1
  • Alternative 3: we add an extra entry below the “Access rights”, named “Required Rights” for users without admin rights
    image

WDYT?

#8

For PR it’s not a problem: users with PR have admin right AFAIR. It’s more an issue indeed if you want to allow it for users with Script right. For those I’d go to Alternative 3 I think. Now there’s the question of what you would display then? Only the required right view, without the admin menu?

#9

Yes, that’s what I had in mind.
That’s also what’s done for the “Access Rights” entry for non-admin users, this entry lead to same content as the “Rights: Page” entry from the page administration, but without the admin menu.

1 Like
#10

I wonder if we shouldn’t use the Info tab (or the edit side panel when in standalone wysiwyg) to do the same as what we do for hidden pages, locales, syntax, etc.

#11

That’s probably more work, but definitely better in term of user experience.
Looking what we did for numbered headings activation, to see if it can apply here as well.

#12

I did some testing and having the selection in the info tab (and edit side panel on standalone wysiwyg) is definitely better in term of user experience as the editor does not have to save and switch context in order to fix a right issue.
So here is my +1

UX for changing document rights
#13

+1 as well.

Thanks,
Marius