Permissions
Table of contents
Background
Permissions, as implemented in MindTouch Deki <= 8.08, were designed to provide the lowest cognitive burden, and as such remain simplified. However, we have the underlying capability in the API to expose a lot more functionality, which would allow for more granular control over content inside Deki.
Work items
A permission reboot would involve:
- New UI - a better screen for managing permissions on a per-page basis
- Removing the "restriction" abstraction layer - for true per-page granularity, we have to remove these pre-made masks of restrictions
- Removing the "roles" abstraction layer - the initial reason for roles was to give a set of flags a mask that could be applied and updated with ease across the system. There is a significant overlap currently between roles and groups, and roles seems to be a somewhat foreign concept - I think the notion of user/groups is a lot easier for people to underestand.
- Allowing granularity with "inherited" permissions - there are use cases where permission inheritance is a bad idea (for example, Moz wants to keep the home-page "read-only", but obviously first-level pages should allow UPDATE ...
- Expand flags - need more granular flags for attaching files, moving vs. delete, commenting
Proposed Changes
New UI
This is a very very early draft (no design really, still fleshing out the flow). (RoyK: As of 24.09, this UI will not work and must be revamped)
The idea behind the new UI is that we will display relevant flags to pages and allow setting these first as an overall restriction ("Everyone can"), then allow for specific overrides ("grants"). Users and groups, as always, can have their grants updated.
Some things I'd like to avoid:
- A super grid of 50,000 checkboxes
- Too much technical jargon (my initial reluctant to approach more granular permissions stems from the ambiguity of roles)
- Hiding the fact that restrictions remove, then grants add (too techie for most people to understand)... the UI should present permissions as purely additive
Deprecating "Restrictions"
Proposal: Remove the notion of "Restrictions" from the API and instead use a custom set of flags for each PUT:page/security operation. This will let us drop another unnecessary table, and remove a layer of abstraction from the API.
The downside to this approach is that we lose the ability the globally define a 'restriction.' This is only really an issue when we add new permission flags, and they need to be retroactively added. However, this can be mollified; if we're adding a new action, then backwards-compat isn't an issue; the restricter has defined a specific set of actions associated to a user - adding new behavior is not a problem. The only problem occurs when we split an existing flag into two separate flags (example: VIEW --> VIEW, COMMENT). I'm not sure how this will be reconciled - (update script?)
Proposed DB changes
- Drop `restrictions`
- Drop `pages.page_restriction_id`
- Add `pages.page_restriction` which has the bitmask of that page
- Add `pages.page_restriction_inherit` as a TINYINT(1) which determines whether permissions should cascade (?)
Deprecating "Roles"
Roles were initially created to create a quick mask that could be used by the front-end to simplify operations. However, with the addition of local groups, roles are largely redundant to groups, without the flexibility of the 1:many relationship groups offer.
We can simplify the operations of Deki by remapping all roles functionality to groups. Hence, upon upgrade, the "Contributor" role would be converted into a "Contributor" group, which would maintain the permission masks from that role.
This also means that users would have no roles until they were assigned into a group.
Proposed DB changes
- Convert all data in `roles` to `groups`
- Drop `roles`
- Add new user data into `user_groups`
- Drop `users.user_role_id`
Allowing granularity with inherited permissions
New subpages inhering permissions from the parent is the typical working general case. If a page is somehow protected, child pages shild be auto-protected as well. In some cases as with Mozilla, you don't want child pages to be protected. This can be accomplished simply by not inheriting parent permissions. -> Checkbox
Undo permission change
Use case introduced by andrewstr here.
- Tag page
- What links here
Files 5
| File | Version | Size | Modified | |
|---|---|---|---|---|
| ||||
| ||||
| ||||
| ||||
| ||||
| Images 5 | ||
|---|---|---|
 |  |  Tabbed grant managergrant_pane.jpg |
 Permission flow? (anbrcyp)permissions_flow.png |  | |
Copyright © 2011 MindTouch, Inc. Powered by
Edit: I just thought about it and realized it would be the mother of all headaches when you consider someone who may not have access to an extension can still be an editor... probably not a good feature to ever try and implement. =) edited 16:05, 19 Sep 2008
For the "removing roles abstraction layer" I suggest that roles are actually more intuitive than groups in this context. So instead of ditching roles, it may be desirable to keep the roles nomenclature and ditch the groups. But, this is a personal preference.
In my opinion, controlling view / edit permissions at the role level is granular enough. It's a fairly simple model that hopefully is easy to implement. To add additional granularity, adding roles-based security to extensions may be a good idea. The way we're looking at DekiWiki, I can see a clear need to "lock down" some extensions so that only certain users / roles are authorized to add them to a wiki article.
Thanks for a cool product and for listening :)
Thanks again.
but it looks like both deki and dnn will converge on the same solution in spirit ;)
This granular controls is exactly what I need for a long time.
I still use version 8.08.2_Kilen_Woods. Is this changes already available in newer versions of MT?