How would you handle user access management with 4 levels and 9+ unique roles?

Question

I've been racking my brain over this, and haven't had any luck in finding existing use cases similar to mine.

I'm implementing the front-end for our website reporting software. We've got some legacy issues to deal with. The biggest issue is that the old version of the application forced users to separately login as different "accounts" to view data.

The "accounts" are more like networks, where we have Corporate, Regional and Location 'networks' nested, with "Location networks" containing the actual items which encapsulate the tracked data. I'm being vague because for some reason my bosses aren't fond of talking about behind the scenes processes publicly...

With the new system we've moved to a user-based login keyed off of their email address. A user login can have access to many Networks/Items with varying levels of access roles possible for each.

Right now we are using a tree control to allow filtering down Accounts for reports and it works great.

Where the trouble is, is in creating the front end for the management of A. Sharing access to accounts and B. Setting the access role restrictions on those shared accounts.

The tree can go 4 levels deep, and there are 9 unique access roles that are required, with more probably needed in the future as we roll more of the old features in to the new app.

Here are some options I came up with, but they each have their own pros and cons:

Account Based Access Set up

This seemed like the most obvious way to do it. I'm running in to the trouble where you may have User access on 2 Corporate Networks, but only 3/9 other access roles on one, and a seperate 4/9 access roles on the other one. In our system, you can only grant access roles that your own account has as well. So what roles do I show next to it? Each account is stored in the database seperately also, so how do we regroup them up? Also, it's possible to create conflicting access groups this way.

Role Based Access set up

Role based access set up removes the problem of conflicting access groups, but then it can get complicated if a user needs many roles... Also, not sure if this would confuse users.

Table Based Access set up

Due to spam restrictions I can't post this as a link but use the same imgur URL and add /Jbudh.png to the end of it.

Tables are easy for our users to understand... but the developer seems to think this could be trouble to reconcile when saving to the database since conflicting access groups could be created again...

How would you solve this problem?

Answer 1

• I've looked at all three options and am confused by all three.

As a user I want to know what I can do with my access rights. Here's my suggestion. I am using Bugzilla's role's as the role descriptions to be more concrete, and in the mock-up calling them 'Special Powers'.

It's a way to summarise, rather than showing zillions of checkboxes.

This model is based on the assumption that a typical user will have identical rights on a number of items, for example extra rights at their own location, and then lesser rights for some locations in the same division.

Details

The tiles like 'Whine Master', 'Bug Wrangler', 'God', 'Pleb' need to be predefined for combinations of special powers that you know are likely. These combinations must be locked down.

In the rights-for drop down, there is an option for 'new rights', so you can create new rights combinations and then give them a name. The interface should suggest a name E.g Bug Wrangler+ for something that is like a Bug Wrangler with an extra special power. If you click on a checkbox without selecting 'new rights' in the drop down, the interface will make the change for you.

---

Edit 1

Showing All Checkboxes

Here, by contrast is what it would look like if you put all the checkboxes in. You might get away with it if you have 9 'special powers', and you should be able to find a neater way of labeling the columns than I have. Certainly using shorter text strings and tooltips for the special power descriptions would help.

This is more an illustration of why I am not keen on trying to show everything without summarizing. Possibly critiquing it will help you to hone your description of your requirements. It might even be what you want. I don't like it. I feel it is showing too much detail all at once - but perhaps you have to.

The zebra striping in the main panel full of checkboxes, if used at all, needs to be vertical, or else the zebra striping of the column titles needs to be lost. An extra space between columns every fifth column would also help.

On this kind of grid it is very easy to accidentally click on one of the boxes when passing over, and then wonder which one you accidentally changed. So cancel and commit buttons, and pending changes shown bolded or otherwise highlighted would be useful.

Master-Detail View using (vertical) Tab Control

Finally an adaptation of the first master+detail approach, but this time doing away with the intermediate names (the names like 'Whine Master' and 'Bug Wrangler'). Intermediate names are useful to speed data entry and summarise, only if the same combinations are being reused frequently. Here they are not.

It's a lot less obvious how to use this than the first version, but it does provide a direct way of linking the items to their details.

I am not proposing that this solution is ready to go as is. Rather it shows a direction you can go in. It is moving more to the style of the file explorer in Windows, with a tree on the left and details on the right. Instead of showing files and details in the right pane, we're showing a list of permissions.

The zebra striping should be dropped, and the fill colour, like the purple border, used better to show what belongs with what. Arrow heads at the ends of the dotted lines could also help.

In Sum

So, three ways of presenting/modifying the information.

• One using intermediate names.
• One showing all the checkboxes.
• One using a master-detail display without intermediate names.