Hello!

Similarly to #538904: D8UX: Redesign Modules Page, it would be good to give some love to our permissions page, who has been surely feeling a bit alone.

Reasoning: the more content types, taxonomies and modules you have, the more you struggle exponentially while managing the permissions page, as it becomes slower and slower to load, and the browser uses up more and more resources.

Example, for a site with 10 content types, some taxonomies and a bunch of modules such as Revisioning, Panelizer, Node menu permissions, plus some others not particularly related to node, it might get out of hand to manage permissions.

Approaches for resolving this could involve one or more of a variety of methods:
- Vertical tabs with AJAX as done in #538904: D8UX: Redesign Modules Page and with Module Filter (7.x/6.x) and Faster Permissions Administration (7.x/6.x)
- Fieldsets as done with Better Permissions (6.x) and Fieldset Helper (7.x/6.x)
- Manage permissions by module in separate pages as done with Faster Permissions (7.x), Node Permissions Grid (7.x/6.x) and Permission Report (6.x)

The better approach being Vertical tabs as per functionality and usability, and also to maintain Drupal uniform.

Additionally, the following UI controls would be useful:
- Filtering and searching on the fly as done in #538904: D8UX: Redesign Modules Page, with Module Filter (7.x/6.x), Faster Permissions Administration (7.x/6.x) and Filter Permissions (7.x/6.x)
- Bulk changing permissions as done in #538904: D8UX: Redesign Modules Page and with Permissions API (6.x), Permission Select (7.x/6.x),
Check Heavy UI (6.x) and All Permissions (6.x)

Related modules (Permissions page):
Better Permissions (6.x) - turns permission groups into collapsible fieldsets
Faster Permissions Administration (7.x/6.x) - changes the permissions page to allow searching and filtering by permission, module and role
Filter Permissions (7.x/6.x) - changes the permissions page to allow filtering by module and role
Faster Permissions (7.x) - manage permissions by module in split pages (really useful)
Permission Report (6.x) - inspect any permissions by user and role
Node Permissions Grid (7.x/6.x) - inspect and manage node permissions
Permission Select (7.x/6.x) - check all permissions
Check Heavy UI (6.x) - check all permissions
All Permissions (6.x) - check all permissions
Permissions API - bulk change permissions (6.x) and API (6.x ported to 7.x core)

Related modules (Modules page):
Fieldset Helper (7.x/6.x) - turns module groups into collapsible fieldsets
Module Filter (7.x/6.x) - changes the modules page to allow searching/filtering and turns module groups into vertical tabs

maybe we are still in time yet to implement this!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lpalgarvio’s picture

Priority: Normal » Major
Issue tags: +Usability, +d8ux, +D8UX usability

added tags, changed priority... hoping the issue is more noticed

lpalgarvio’s picture

Pancho’s picture

lpalgarvio’s picture

lpalgarvio’s picture

but that is outside the scope of a UX remodeling

blacklabel_tom’s picture

Priority: Major » Normal

Hi,

Has anyone had a look at the speedboxes module as an addition to the permissions page? Certainly looks like it would be useful when you need to update a lot of permissions at once, say if you wanted a new administrator role to be able to edit all the content types on your site.

http://drupal.org/project/speedboxes

Cheers

Tom

Bojhan’s picture

Version: 8.x-dev » 9.x-dev
lpalgarvio’s picture

thanks blacklabel_tom!

xjm’s picture

#30843: Redesign permissions page appears to be mostly a duplicate of this issue. Closing that in favor of this since this issue has much more current information.

xjm’s picture

Title: D8UX: Redesign Permissions Page » [META] D8UX: Redesign Permissions Page

This is actuallly a large discussion that could incorporate several smaller changes.

Bojhan’s picture

Title: [META] D8UX: Redesign Permissions Page » [META] D9UX: Redesign Permissions Page
Bojhan’s picture

Issue summary: View changes

minor changes

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Issue tags: +minor version target

We could introduce a new permissions interface to a minor version - might have to be in a module and only enabled by default on new installs, but moving back for now.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Interesting to explore this with prototyping.

catch’s picture

Title: [META] D9UX: Redesign Permissions Page » Redesign Permissions Page
Category: Feature request » Plan

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ckrina’s picture

I’ve been doing some search and explored reflexed in this wireframe. So before going further I’d like to share it here to get some feedback:

First, I’ve tried to find the 2 main goals for the page:
A. Work with permissions, change the current state.
B. Visualize/check the current state.

The main pain problems is that it’s become really hard to manage for the amount of information we have there. Some contrib modules have proposed some really interesting solutions:
7. Bulk operations on permissions, like we have on content lists, or even something more interactive like: https://www.drupal.org/project/speedboxes.
8. (green). Filter permissions. See permissions filtered by name, by group name and by checked/non checked (https://www.drupal.org/project/fpa). For example, you want to be sure what permissions an Editor have and not seeing all the other ones.

If we focus on the visualization itself, one really interesting idea that influenced my decisions here was this issue: #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions, because if we’re able to place the hard & most used permissions in its own pages, this page is not the only place where the work with permissions happens anymore.
Some more the proposals:
1. Group permissions like it’s done in the Extend page. It should be the first step to make easier to visualize&scan the page. An MVP would be just group them and keep the alphabetical order, and an enhancement could be actually ordering them by close concepts.
2. Another thing that could be changed would be also grouping roles. There’s an interesting contrib module called Personas doing something similar adding this new layer for roles[link].
3. Quick visualization of permissions by density. The more permissions a role has, the darker it looks. It can be useful to also have a quick textual visualization too with the amount of permissions (i.e. 2/3). The idea is to get something like that:

4. Collapse groups, open in an accordion-like interaction.
5. Another step for visually simplifying the UI would be hiding the description of each permission, readable when you click( in a modal or an HTML detail pattern).
6. Show/hide roles to make it easier to compare them or check the info for some of them. They should be able to be added again.


SKAUGHT’s picture

#20.8
'Apply Changes' tooltip: Looks like person setting a permission will have to verify each time they click a checkbox.

ckrina’s picture

@SKAUGHT you're right, I was thinking this only in case something like https://www.drupal.org/project/speedboxes is implemented or you want to save only some of the changes you've done. Otherwise, probably a more prominent action bar with the save button would be enough.

Thanks for the feedback!

SKAUGHT’s picture

bbuchert’s picture

I like the designs. Maybe grouping permissions with an accordion can help: https://i.stack.imgur.com/ij4Xe.png With including check boxes for the main category maybe the permissions can be simplified even more. For example permissions for nodes could be set for all node types together. Once expanded they can be set for each node type separately.

Also putting the save button in a more accessible place would be great so you don't have to scroll down each time you want to safe,

dqd’s picture

Hm, I really don't like to be the party killer, but I think the main issue with the permission page is not the design. The desgin issue is only a sign for showing underlying conceptional issues it has by having all per module upcoming permissions just dropped in a container. Visually hard to seperate even if grouped. The same goes for entity forms getting cluttered when using more then 10 or 20 fields. What I want to say is, while this issue IS ABOUT design of the permission page it can be too early to discuss the design as long as we do not agree about if and how the permissions gonna be grouped or paged or even placed differently in future, e.g. by each component having permissions to set up, or both. In the world D8 and higher we will have an explosion of permissions and we deeply need a basic solution for that to handle. While we thought in earlier days it would be better to have such senstive settings all in one place, the new mass of settings changes this view a lot. Look at digital audio workstation software for music studio computers. Their most sensitive settings are the connections between all the recording tracks, channels and effects. Wireframes are great for certain purposes and are provided as an additional(!) set up page for this workstations but they also provide the settings per channel and the majority of engineers use the settings per channel to know exactly what they do and WHERE they do it now. It would become a mess for 100 channels and so it would for 20 user roles and 40 entity types to be forced to set it up in wireframes only. Especially on mobile devices.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

rcodina’s picture

I think the best approach is the one seen on https://www.drupal.org/project/fp. It just saved me the day in an old D7 with lots of permissions and roles. It's just a matter of reducing the amount of information to display each time! In order to improve this approach, the permission of selected module could be shown using AJAX instead of loading them on a separate page. Also, this "fp" needs a filter by role which https://www.drupal.org/project/fpa already has. Notice in this old web I'm fixing "fpa" was too slow so any solution shouldn't show all permissions on first load.

To sum up, I think the best solution would be to do a mix of "fp" and "fpa" modules.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

nod_ credited RobLoach.

nod_ credited eigentor.

nod_ credited stBorchert.

nod_’s picture

Issue credit from the 15 years old issue that was closed as duplicate of this one :p

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Anybody’s picture

Issue credit from the 15 years old issue that was closed as duplicate of this one :p

Sadly many points from this issue are still relevant! ;)

Anybody’s picture

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.