Redesign permissions page

I really like the idea, but with a few comments:
We should not start introducing side-tabs. Ratheruse tabs across the top, in some manner. That is consistent.
The JAvascript must off course degrade well. In fact, it should by default not use any JS, just show links to pages. If it is proven that the browser supports it, js can be switched on (automatically, off course).

Good idea. We could use collapsible fieldsets as already used in the cvs head.

In a way, I kind of like the side buttons. They might look weird and cluttered next to a left navigation menu - especially in a fixed-width theme - but it "scales" better.

Tabs along the top are going to be problematic. After a certain number of modules, you're pushing things out way too wide. A vertical arrangement does not suffer the same problems, which is why I wouldn't reject it outright.

My biggest problem with the access page now is its height. After scrolling down to see options, I tend to forget which column belongs to which role. Also, when we add a number of roles, the screen gets way too wide.

Breaking them up by module is useful, and perhaps this can lead to folding the roles so they don't "push out" too much. Great Start!

Adding another column to a matrix that is already very wide if you have more than just the basic roles doesn't really seem to be a good idea.

I agree.
IMNSHO we should get rid of that matrix. OR better: leave the matrix there for thos who thing they need it, but come upp with a new idea/concept.
The matrix does not scale, we all know that. And I am not talking about five modules and thre roles. But about fifteen roles and twleve modules with /loads/ of permuissions.

Let us please first think about this a little more. (mockups are great for this, hint)

Just to point out the obvious, the matrix makes it easy to compare permissions for roles. It also allows bulk editing of permissions for multiple roles at a glance. We will lose these when we junk it. It does not scale though.

As far as keeping two interfaces, it may end up being confusing, and add to code bloat.

fajerstarter: The javascript permission groups by module are not really my cup of tea. I personally *like* having all the permissions visible at once.

However, I find your group checkboxes mockup really great. Now, if *that* was dynamic, as in show/hide columns with JS, it would roxr.

Just my ¢2.

Yeah, a bit bold. I nevertheless like it. However, you need to make sure to not display the selection bar, if JS is not available.

Why not always have the role name column headers displayed rather than on hover?

I tried the colors using a contrast checker at http://www.snook.ca/technical/colour_contrast/colour.html. #AAAAAA and #E9E9E9 have a difference of 189 when the W3C recomends 500. I'd recomend making the text #424242, which makes a difference of 501.

Oh and I made a patch for tbody: http://drupal.org/node/28777

Regarding thead, that JUST hit HEAD tonight:

http://drupal.org/node/28777

Functionality-wise, the page looks great. On my system, however (Konqueror 3.4.2 web browser), scrolling the page is then very slow. My hardware is reasonably modern, so I'm assuming the Javascript is slowing it down somehow. Something to look into.

Wouldn't making each module its own fieldset, though, work as well? We'd lose the massive-table, but that may or may not be a bad thing.

I like the idea of hidding some roles from the matrix and having collapsible groups. Side tabs are OUT! I can't affort an Apple with a 30" LCD display yet.

Moving to 6.x-dev.

Well since 6.x is out and I personally would like to see this added in a more friendly way I will mark this for 7.x.

My viewpoint towards this would not to add a side bar but a horizontal group of dropdowns where admins could sort based on there criteria. Similar to how Views 2 handles finding views blocks/pages/etc... for drupal 6.

Here is a first proposal for the D7 permission page.
I've rearranged the permissions to look more comfortable (kicked off this ugly table).
The patch is based on the work of Frando in #396478: Searchable modules page.
As an addition we could add the search functionality as soon as #396466: Support custom success callbacks in ahah.js is in.

Uh.
Note to myself: running all tests before submitting is much better.
Applied permission form changes to all tests. Should pass now.

Ok, next try.

I'm not sure about using vertical tabs. It would be slower for me as I can't use my browser's search feature anymore to find the permission I'm looking for. At the same time, this could avoid the need for search and most other people might not be searching to begin with.

We could use the same kind of search, Frando invented in this issue.
Having this you could simply enter the name of the permission (or a part of it) and all matching permissions will be listed in a new tab.

The vertical tabs look very nice in the screenshot. I think they would make a great usability improvement, as long as they were searchable in some way.

Having said that, however, I am worried about what this will do to performance if people have >20 modules installed (which does and will happen). The permissions page already loads super slowly when you have >20 modules just with the tabledrag.js. The vertical tabs js would slow it down even more.

However, this isn't a show-stopper if you used some sort of AJAX vertical tabs implementation, similarly to the Add Pane modal dialog in Panels 3. I personally love the Panels and Views UI concepts, and think it would great if more of them were incorporated into core. The AJAX definitely loads faster than trying to pull the whole thing at once & apply JS behaviors to it.

I've done some more work on it and added search functionality (as in #396478: Searchable modules page).
Attached is a screenshot of the search (unfortunately I can't create patches here so there is nothing new to test atm).

I like the vertical tab redesign, but I just realized that it adds an additional step for people that are trying to "select all" permissions for a given role. Granted, there's a module that takes care of that (http://drupal.org/project/adminrole), but I still think that there should be some sort of "Select all for this role" or "Select all for this category" option in core. Is that possible?

"Select all for this role" or "Select all for this category" option in core. Is that possible?

Yes, with some jQuery magic it should be possible.

However, I noticed one thing with the search tab (don't know how Frando plan to fix it on the modules site): if you have some search results the items shown there are duplicates of the "real" items on the module specific tabs. If you check one of them (or uncheck) its not clear in which state the permission is. Both checkboxes needs to be synchronized (if you click the one on the search tab the other should change its state and the other way round). This (hopefully) can be done with some jQuery.
I'll try to post a new patch including the search functionallity (and update #396466: Support custom success callbacks in ahah.js) tomorrow.

As I see it, the primary problem with the permissions page is simply the amount of permissions to sort through. One way to help the situation is to isolate some of the clutter into their own tabs. For example, content type permissions can get very long and repetitive, especially on more complex sites. What about isolating these permissions in another tab to shorten the main list of permissions and make them easier to locate? The same goes for field permissions, especially if they get added into core. The tabs could be: Primary permissions | Content type permissions | Field permissions. (not sure on "Primary permissions" as a title).

Do others see this being a positive route to investigate?

rickvug:

That would be more helpful than the Vertical Tabs approach for my site, at least, where most of the permissions are content type or field related. The problem with the Vertical Tabs, as I said above, is that it still requires all the permissions to be loaded before the JS can sort them into the vertical tabs. This would slow the page down even further in my case.

@rickvug:
There is no need to group permissions that way (IMHO). You can simply search for permissions (e.g. "edit own", "create") and will get a new tab ("Search results") with all matching permissions (as shown in the last screenshot).

@EvanDonovan:
Even if there's no Javascript at all you'll have to load all permissions. I can think of no way on how to load only a few permissions (grouped by whatever), but only if JS is enabled.

Ok, here is a new patch (including search functionality).
It is based on #396466: Support custom success callbacks in ahah.js so you'll have to apply this patch first before applying the one attached here.
There are some issues I can't fix. Maybe someone with deeper knowledge of Drupal behaviors and AHA can look on it.
If you search permissions you have duplicates of the "original" permission checkboxes in the new search tab. If you click on one of them (for example "authenticated user" for "access content") the corresponding checkbox under the "Node" tab changes its status also. If you click on the label only the original checkbox is changing (due to the fact that the label points to it and not to the one in the search pane).
If you now click on the mentioned checkbox within the "Node" tab the checkbox in the search tab didn't change its status.
Probably this can be done with some jQuery (I've tried but failed).

The other issue is AHAH related: try hitting Search without entering a search string. You'll see an error message.

Now with modified contact.test.

@stBorchert:

Perhaps I wasn't as clear as I meant to be. What I mean to say is that all the permissions will load on the page & then they will be grouped into the vertical tabs, because the JS executes on $(document).ready. That makes the page load even slower than it already does with tableheader.js being applied on $(document).ready & that's already too slow for my Drupal 6.x site (which has hundreds of permissions).

That's why I liked the idea of grouping different categories of permission on different "local task" tabs, because then they wouldn't all have to be loaded at once. AJAX could theoretically accomplish the same thing, for those who have JS enabled.

Perhaps I wasn't as clear as I meant to be.

Hm, I thought I know.

grouping different categories of permission on different "local task" tabs

The permissions under these tabs are not searchable (without further database requests).
And if you have hundreds of permissions, how much groupings you'd like to have? More than 5 tabs aren't really UI-friendly, IMO.
And would it really reduce the length of the lists then?

Its tricky and I hope some of the UX-guys can post some notes about it.

subscribe

@stBorchert:

I agree it's a tricky issue & perhaps my situation is an edge case (although as long as there are mega-modules like Ubercart, Organic Groups, Panels, and Views, I'm not so sure). Here's the alternatives I would prefer, in descending order of preference:

1) AJAX loading of permissions into the Vertical Tabs, so they wouldn't all have to be loaded at once. (This is similar to how the Panels 3 module lets you add blocks to your panels.)

2) rickvug's suggestion in #35 to break up permissions into 3 local tasks: Primary permissions | Content type permissions | Field permissions. I agree that 4+ tabs is not usable. We would lose a certain amount of searchability with this option, but I don't think that would be too bad, since the content type permissions and field permissions are each pretty self-contained. After all, in Drupal 5, the field permissions were part of the CCK UI, not part of the permissions page at all.

3) The current patch on this issue, but with an option somewhere (even as a variable in settings.php, I don't care) to disable JS on the permissions page for people like me who wouldn't be able to load the permissions page with the JS active, since it would most likely freeze the browser.

Some UX feedback: in the 3 usability lab tests we've done, no issues were found on the permissions page.
Yes, it's a lot of checkboxes but everybody understands what it does and finds what they are looking for fairly quickly and easy.

Vertical tabs is a mechanism for hiding/showing multiple screens that do not relate to eachother much. That's why they are ok on the node/add form for stuff like menu, author, etc. settings. Here they are not such a good idea because they would split up this page into sections with ambigous labels that you first have to choose between to maybe get shown the right permissions. It would add to the cognitive load, not lessen it.

So my first question would be, what are you actually trying to fix here?

I agree with yoroy in the last comment. Yes, the permissions page looks intimidating. Yes, it's full of checkboxes. Yes, the vertical tab solution looks "cooler." But yoroy's comment strikes at the heart of this issue -- apparently the permission page, as odd as it is, is one of very few pages (perhaps even the only one) that people seem to understand in its current form.

What about something similar to Views2. A simple way to filter permissions based on a certain criteria.

Maybe we can have a "Role" select box or a "By module" select box. This way we can at least crop out the permissions we aren't interested in changing.

On a small chime in, rather than splitting permissions based on what they are for (the general / content / field permssions above), what about trying to split them based on likely roles - eg maybe use to View / Modify / Administer?

Then, all the Administer permissions are kept in an area away from the View permissions, so that unsuspecting Admins are less likely to grant Administer permissions to untrusted people. It could also help clarify the intention of some permissions that are not described clearly.

@yoroy
Did you test the page with 10+ roles enabled?
I admit: the checkbox grid is one of the layouts a person can understand very quick but if you have lots of roles this page is just unusable (unless you notice you can display permissions for one role only).

I've found this issue while digging through the D7-queue and thought "hey, what a great idea. this would be awesome." (and still think its much cleaner).
And I didn't tried to "fix" something. It was just a page that doesn't makes me happy and this issue did show a (IMO) good way to make it better.

PS: this post shouldn't sound offended or miffed. Its just my point of view. And I like the vertical tabs :-)

O.K installed the patch. Here a Screenshot of node module permissions:

Note the scrollbar on the right for an impression how long this goes at the bottom. Now imagine that with 10 roles and 17 content types. Happy scrolling :)

Without a doubt the grid that breaks the page with many roles is an issue, which IMHO should be adressed by a filter for roles also. filter_perms does exactly this:

While the filtering has some issues and could be way more intuitive, it must be debated how to get the best of both worlds: a search field is quick, but if you don't know what to search for it does not help. Maybe a fuller set of filters might help.

This gives you a nice little chunk of the permissions table, that is manageable and scannable. As the permission page can be security-critical, this should help avoiding severe mistakes from not-so-experienced users.

When using this, I experienced a lot more relaxed use of the page and an improved confidence not to have overlooked something.

As to the vertical tabs: Especially when you gots lots of modules, the value of them becomes debatable. As yoroy mentions, this usecase contradicts the UI Guidelines for them: http://drupal.org/node/373788

I didn't think of a filter. I like that way better than the vertical tabs, or splitting the permissions between several local task tabs. That way I can look at as much or as little of the page as I want, and if the filter can be set to default to either "None" or "All", then I don't ever have to try to load the whole grid at once.

I love eigentor's "Permission Filters" idea. If we can get a consensus on the direction we should take, we should at least make usability a key point in this patch (since that is Dries goals for D7).

I think "Permission Filters" and "Filter Permissions", while descriptive, might confuse new Drupal users. I think a word like "Sort" might work better than "Filter" from a UX point of view.

Well actually it is not an idea, but a module... http://drupal.org/project/filter_perms

wow...I kinda feel stupid now. Well, I still like the idea of using filters as opposed to the vertical tab + search idea.

I just installed the filter_perms module, and find that it is just what I have been looking for. I think the concept behind the module is definitely core-worthy, although the execution could probably be improved a bit.

For example, I think that <All Roles> should be selected by default, so that people will just have to choose which modules to view permissions for and then click Submit. Perhaps there could be an option besides <All Modules> called <Core Modules> which could also be selected by default. That way, you would just have to click the Submit button to view the core permissions for all roles.

your turn

So my first question would be, what are you actually trying to fix here?

Just to chime in with my experience, administrating a complex site with many roles and modules quickly leads to repetitive strain injury.

The key troublesome use case for the permissions page is that of setting a large number of permissions for a new role.

I would like to be able to click once, and simply drag down to light-up a number of permission flags at once. I would like to click a single button to “check all”. I would like to copy permissions from one role and paste them to another, module by module or globally.

I am toying with the idea of a CVS import/export module for the permissions page, allowing the admin user to export the permissions matrix, manipulate it in Excel (copy and pasting, filtering, etc), save it, import it back into Drupal and have it update the system permissions.

Perhaps this spreadsheet metaphor is suitable for a re-designed Permissions page?

Still not convinced, but maybe later :)

@EvanDonovan: The main reason I made the filter_perms module was because I have a site with a ridiculous amount of roles and permissions. Even doing only core modules + all roles would give me an undesirable wait on first load. If you have suggestions for the module, though, feel free to add to the filter_perms issue queue.

It looks like it will still be in contrib for d7 at least...

@cYu: It's the same way on the site I use your module on. The suggestions in #55 though were to make the proposal more acceptable for people who don't have a large number of modules or roles though.

I think keeping it in contrib is actually probably the best idea.

This page hurts both my browser, and my brain, when loading it up. We have both Vertical Tabs and States as part of Drupal core now, might be able to take advantage of them. Despite it being called "Vertical Tabs", it does take up quite a lot of horizontal space, might have to do some mock ups and browser tests to make sure it doesn't take up too much of the screen.

Cleaning up the tags, as there isn't yet a design mock up/patch to review. Also adding to my wish list.

This patch makes the permission rows collapsible, like on the Testing page, but I'm not sure this actually helps the issue of this page being gross...

Well, the filter permissions module is a mock up in itself :)
There is a version for D7 now.

The only thing that bothered me about the module (and does so still) is that it should default to show all instead of show nothing without active filters. http://drupal.org/project/filter_perms

http://drupal.org/node/1161762

...subscribing.

I'm using 'permissions' tag to group some issues.

...no reason to remove previous tags though.

Not that I'm against the idea of collapsible rows but why not separate them by pages? For example instead of using collapsable rows we would link to another page that would contain said permissions. Just brainstorming here.

oh my bad, I shouldn't have tagged it for mobile initiative just yet...

Closing in favor of #1765576: Redesign Permissions Page.