-
Notifications
You must be signed in to change notification settings - Fork 0
Roles and Access Design Doc
#(WIP) Roles and Access Design Doc
This document explains the current design plan for roles and access rights.
##Permissions Grouped by Affected Object ###Post
- Create
- Edit Own
- Edit Any
- Delete Own
- Delete Any
- Move
- Lock
- Attach Files
- Download Files
- Create Poll
- Edit Own Poll
- Edit Any Poll
- Lock Own Poll
- Lock Any Poll
- Delete Own Poll
- Delete Any Poll
###Thread
- Create
- Edit Own
- Edit Any
- Delete Own
- Delete Any
- Move
- Lock
- Merge
- Sticky
- Self Moderate
- Split
###Board/Category
- Create
- Edit (Name)
- Move
- Lock
- Visibility
- Merge
- Delete
###User
- Create
- Edit Own Profile
- Edit Any Profile
- Delete Own
- Delete Any
- Ban Users
- Set Any User's Permissions
- Avatar
- Signature
###Group
- Create
- Edit
- Delete
###Messages
- PM User
- PM Group
##Permissions Design The permissions design consists of three objects: Users, Groups and Permissions.
###Users User level permissions override permissions inherited from a group. A user's actual permissions are calculated by first taking the highest permissions from each of the users groups, then subtracting all user level permissions which were revoked.
User level permissions are optional and used to limit a user's permissions.
var user = {
...
groups: [], // Array of group ids
permissions: {} // Permissions Object which overrides group permissions
...
};
###Groups Groups consist of an unique id, a name, and an array of members (user ids). A member can belong to multiple groups, in which case the highest permissions are taken from each group then compared to the user level permissions to determine which permissions were overridden.
var group = {
id: 'xyz123' // Group Id
name: 'Example Group', // Name of the Group
members: [] // Array of User ids
};
###Permissions The permissions object has properties which correspond to an action which can either be performed (true) or not performed (false) by a user.
var permissionsObj = {
posts: {
create: true,
edit_own: true,
edit_any: false,
delete_own: true,
delete_any: false,
move: false,
lock: false,
attach_files: true,
download_files: true,
create_poll: true,
edit_own_poll: true,
edit_any_poll: false,
lock_own_poll: true,
lock_any_poll: false,
delete_own_poll: true,
delete_any_poll: false
},
threads: {
create: true,
edit_own: true,
edit_any: false,
delete_own: false,
delete_any: false,
move: false,
lock: false,
merge: false,
sticky: false,
self_moderate: true,
split: false
},
boards: {
create: false,
edit: false,
delete: false,
move: false,
merge: false,
lock: false,
visibility: false
},
users: {
create: true,
edit_own_profile: true,
edit_any_profile: false,
avatar: true,
signature: true,
delete_own: true,
delete_any: false,
ban_users: false,
edit_user_permissions: false
},
group: {
create: false,
edit: false,
delete: false
},
messages: {
users: true,
groups: false
}
};
##TODO
- How do we incorporate board level permissions, such as a board wide disabling of polls or self moderation. Should we even allow board level permissions?
- There is room for improvement with the grouping of permissions. Should we group moderator/admin level permissions apart from user level permissions?
- Possibly remove some actions such as
merging/splitting
and lumping them in withedit
. This entirely depends on how granular we want the permissions to be. The more granular the permissions become the more confusing the user interface will become. Need to discuss the benefits of making the design more/less granular.