Accessmap Concept Example
Table of contents
- 1. Overview
- 2. General Layout
- 3. Examples
- 3.1. GUI Layout
- 3.2. Complex Filter UI
- 4. Summary
Overview
This little brainstorm is being written because of difficulties I encountered while testing out my restriction modification. Basically, the current UI model only lets you look at one page at a time. If you want to audit the whole system, you literally have to load every page and bring up the restriction dialog in each one. Even checking all the grants manually doesn't quite cut it, because you still don't know exactly what access an individual has without logging them in and checking what functions they have available on each page.
Unfortunately, any useful site level UI for grants has to get around the fact that grant information can get annoyingly complex. My current thought is that CSS can be used with the restrictions/permissions of a given page to create a visually informative display. A user could then cut down their point of view by filtering with a user or group ID. Using those two methods, you could display a tree-style UI for auditing the wiki's grants and access. I'm going to refer to it as Accessmap for now.
Some of the features I'm listing here probably aren't practical (crappy investment/return ratio), which is why I'm calling this a brainstorm instead of a proposal.
General Layout
Here's the basic rules and goals of the Accessmap:
| Requirement | Target |
| Role | CHANGEPERMISSIONS or ADMIN |
| Visual Formatting |
|
| Filtered Output | Permit the user to filter by at least one user/group name (preferably more). This could get very complex, but it should be usable with something like the current restriction UI; feed selections into a 'filter' box. Output is displayed from the filter's point of view (i.e. displays the efective permissions/grants of the filter for each page). Limited Feedback rule should be followed when creating output. |
| Direct Access | The user should be able to directly access each page's grant popup using the map. When the popup is finished and grants are updated, the Accessmap will display the fresh results without having to manually refresh/navigate. A user could also benefit from some way to lookup (not modify) the relationships between users, groups, and roles. |
Examples
Examples are loosely based on the MindTouch site due to a certain lack of creativity. Obviously, some liberties were taken in the form of guessing how the MindTouch wiki is actually setup. Hopefully, those liberties make it easier to understand the intent of the examples even if they are incorrect.
GUI Layout
This covers the general idea and functionality of an Accessmap. This is my 'Cadillac' version of the tree UI... which means it probably isn't worth implementing 100%. Something close to the way the current sitenav menu would probably be more than enough.
For this example, the following formats were used:
Restrictions
Simple color formatting of a page's node informs the user of the general restriction level of a page.
Filtered Output
This example displays how a simple filter would be entered. The 'Effective permissions' line displays that user's standard or 'Public' permissions. The effective permissions are calculated based upon any additional permissions that may be added due to group membership. For a user who had a base role 'None' but was granted additional rights by a 'Viewer' group, the permissions rectangle would display viewer level rights.
Depending on a site's design and how permissions are being used, a manager may see a predominance of red (denied) or green (extended) permissions. This example primarily results in denied permissions.
Permissions
Permissions are displayed as a high contrast rectangle with simple color formatting to display granted, denied, gained, or lost permissions.
A large rectangle is broken up into smaller rectangles, one for each permission, and creates a simple color pattern for any given set of permissions. Hovering over the rectangle will provide a popup box with the full detail of the permission set (HTML 'title' effect).
For example, this rectangle displays a user with a base permission level of the typical 'Viewer' role, but with enhanced permissions due to a grant (UPDATE, CREATE, DELETE are added).
Visual Heirarchy, Direct Access & Limited Feedback
This example uses an expandable directory tree style. Hopefully, intuitive and familiar for most users. Due to size restrictions, may need to go to a docked node display once the user goes to a certain depth, or use a scrolling iframe.
Each page node has a dropdown menu that gives the manager an easy to view list of existing grants for a page, as well as the option to open a page's restriction popup. Each grant listed includes a simple icon that identifies the grant as targetting a group or individual.
The concept of limited feedback is demonstrated in the last node, which is greyed out and provides no information on the access level of that page. This means that the manager is still able to access/browse that page but cannot control another user's access.
Complex Filter UI
This example focuses on the idea of a more complex method for evaluating and creating a filter (more than a single value). It includes a possible way to review user/group/role relationships. The main point of the 'advanced' filter is to give a user some way to look at how users/groups/permissions are all tied together without requiring them to use those specific admin pages.
This example only covers the general layout of a complex relationship&filter UI.
Filtered Output
The 'advanced' filter is designed to accept multiple group/user names for creating permission results in the tree UI. This doesn't feel like a large value added feature, but could be used from time to time to verify that current grants allow a certain set of groups or individuals the correct access. It could also be useful in determining the effect for a particular individual if they are added to or removed from a group.
Summary
Those are the two major ideas of the Accessmap. I'm still working on getting some sort of @gui version to play around with, but no real ETA on that.
If you have any feedback on what is or isn't useful about this or any suggestions for improvement, please let them be known on the forums (http://forums.developer.mindtouch.co...ead.php?t=3866) or in comments on this page.
- Tag page
-
- What links here
Images 6
