Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIX confusing UX of CMS permissions: Groups and Roles #8620

Open
11 tasks
newleeland opened this issue Nov 20, 2018 · 0 comments
Open
11 tasks

FIX confusing UX of CMS permissions: Groups and Roles #8620

newleeland opened this issue Nov 20, 2018 · 0 comments

Comments

@newleeland
Copy link

newleeland commented Nov 20, 2018

Description

Currently Security groups permissions have a really confusing UX as:

  • Permissions given to a group via Roles are not visible within a Group, you need to drill into Roles to figure it out.
  • Permissions under CMS access and Content permissions conflict each other (Unclear effect of "Edit any page" content permission #8487) (eg. you can edit pages but not be able to access them)
  • Several different permissions use similar terminologies for completely different scenarios.

Proposed solution

Improve visibility of permissions in Security/Groups by reducing the duplication of CMS permissions in different parts of the CMS.

The majority of SiteConfig permissions are already available within Security Groups, just configured in a different format. This causes confusion around what is set, there are 2 areas managing the same permissions while being out of context from each other.

  • Move 2 SiteConfig controls Who can edit pages on this site? and Who can create pages in the root of the site? into Security group permissions as per design. (relates to FIX confusing UX of CMS permissions: Settings (SiteConfig) #8622)
  • Combine UI of Permissions tab with Roles tab within a group (Roles tab only appears, when a role is created atm) and rename this tab to Roles & permissions. The Role tab only has one form field and shouldn't be hidden from the permissions view and has exactly the same permission options.
  • Surface permissions set within a Role in the Group/Permissions tab as disabled checkboxes.
  • Create tooltip for disabled selected checkboxes: This group already has been given access via "Roles"

Reduce granulation of permissions for different sections

Under Content permissions, we have Edit any page and Edit any file. We probably don't need this level of control for a separate section of the CMS. This confuses the user with too many options to manage and we wouldn't offer this level of control to all content types. Having "Edit" permissions and access to the Files area and Pages area would provide the majority of businesses enough control.

  • Our suggestion is to remove "Edit any file" and "Edit any pages" and replace with one general edit setting "Edit in CMS" for all content, under "Content permissions" title. This change could be debatable?

Clarify what Edit means and allow for true "Editor" and "Publisher" roles.

Currently "Edit any pages/files" permissions allows publication actions, i.e. publishing, unpublishing, archiving, deleting and releasing from campaigns, pages and files. We could remove the need for modules like the Advanced Workflow if we allowed for "Edit" permissions and "Publish" as separate controls.

  • Rename "Edit in the CMS" to "Full publish rights".
  • Create a new option "Edit only".

Removing duplicate permissions in groups

Under "CMS access" you can give people access to specific sections of the CMS, this indirectly sets the expectation that it can be viewed when there is other view-related options under "Content permissions".

  • Remove the View any pages option under Content permissions, and rely on access to the Pages section to provide view access.
  • All sections within CMS access should be view access, unless given the necessary Content permission. (This would address Unclear effect of "Edit any page" content permission #8487)

Considerations for additional admin areas: additional Models added by modules under CMS access, would default to allow access.

Clarify terminology

Roles and access permissions title maybe confused with CMS access title and the Roles tab. A clearer title is required here.

  • Rename title "Roles and access permissions" to Manage roles & permissions
    in Security groups

View draft content option controls who can view URLs of draft pages (i.e. ?stage=Stage), given they are logged in. This maybe confused with the permission to view draft content in the CMS.

  • Move this setting to Content access, under "Access to Pages section". Rename View draft content to View draft content on website via URL.

Wireframe flows

Select: Security(groups, roles)
https://projects.invisionapp.com/dsm/silver-stripe/silver-stripe/section/components/5bf228be8d9a690013f1ae39

Related to:

#8622
#8625

@newleeland newleeland changed the title FIX confusing UX of CMS permissions FIX confusing UX of CMS permissions (draft) Nov 20, 2018
@newleeland newleeland changed the title FIX confusing UX of CMS permissions (draft) FIX confusing UX of CMS permissions: Groups Nov 20, 2018
@newleeland newleeland changed the title FIX confusing UX of CMS permissions: Groups FIX confusing UX of CMS permissions: Groups and Roles Nov 21, 2018
@silverstripe silverstripe deleted a comment from newleeland Jan 10, 2019
@sminnee sminnee removed the type/bug label Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants