Delegated user administration
Table of contents
- 1. Introduction
- 1.1. Intended Audience
- 1.2. Additional information
- 1.3. References
- 2. Status
- 3. Functional Specification
- 4. Technical Specification
- 4.1. UI requirements
- 4.2. API requirements
Introduction
I am investigating using MindTouch to provide a collaborative system for many different groups, where some users may be a member of more than one group. There are two options that come to mind:
- Run a single wiki, with permissioned hierarchies (/Team 1, /Team 2 etc)
- Pros: The same user can be granted access (via group membership) to different hierarchies
- Cons: Only people who are trusted across all the teams can be given administrator rights
- Many separate wikis
- Pros: Each wiki can have its own administrator, allowing delegation of user administration to the team leaders
- Cons: Users are not shared amongst the wikis; the same user has to exist in multiple places; more administration overhead; no inter-linking between wikis
This spec proposes a third option, whereby you can grant permission to a user to see a portion of the Control Panel, which would allow them the following options:
- Create new users
- Grant users membership to the groups that they are already a member of
Intended Audience
The intended audience of this feature is anyone who wants to allow "sub-administrators" to a section of their wiki.
This should be a feature in MindTouch Core, as its primary proposed application is for a non-profit organisation.
Additional information
References
- Bug 4835: Permission system should be more granular
- Forum: User-only administrator
- New operations
Status
Initial scoping by crb
Functional Specification
Use Cases
Assume a page hierarchy with permissions assigned similar to this:
- /Team 1 (Admins, Group 1) - /Team 2 (Admins, Group 2) - /Team 3 (Admins, Group 3)
A number of users exist:
- Alice (member of Group 1)
- Bob (member of Group 2)
- Chloe (member of Group 1 and 3)
Bob now wants to invite his colleague David to collaborate on Team 2. He would create an account for David (or David would create his own account, if this is allowed), and Bob would then elevate David to being a member of Group 2.
In a similar fashion, Chloe could grant access to Groups 1 and 3.
Further, if the organisation reassigns Alice from Team 1 to Team 2, Chloe should be able to remove Alice from Group 1.
Non-goals
This feature does not allow changing of permissions assigned to page hierarchies; for example, Alice cannot change the permissions of the /Team 1 hierarchy to grant access to another group. (If MindTouch supports nested local groups, it may be possible for Alice to achieve this by adding Group 2 to Group 1.
Technical Specification
UI requirements
API requirements
- Tag page
- What links here
| Images 0 | ||
|---|---|---|
| No images to display in the gallery. |
Copyright © 2011 MindTouch, Inc. Powered by