Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another member of the Core Development Team before making changes.
The roles system allows for granular Server-level and Workplace-level privileges to be set and enforced.
The scope of this specification is to explain the roles system, its flexibility and granularity and the difference between Server and Workplace roles.
There are two server roles: Administrator and User. If a certain user is not an Administrator of the server, this 'role' is made invisible to them. However, if a user is an Administrator of a server which they are connected to they will have an extra option to visit the server's 'Control Center' in the 'Manage Servers' pane (see mock-ups).
The Administrator of a Mira Server can configure the default Workplace roles and set overall limitations. For example, the Administrator of a Mira Server can set it so that no users can create Workplaces on his server but the Administrators alone, or all users can (which is the default). This would be an overall limitation. Another overall limitation would be either allowing users to register accounts freely on that Mira server or requiring confirmation from the Administrator before being added to the users database. The Administrator can also configure the default Workplace Roles which a Project Manager, the creator of a Workplace, can assign an invited user to when they accept his invitation to join the Workplace. Please do note that a Project Manager can configure, create and change the roles of the members of his Workplace which will apply to his Workplace alone (more later).
The Administrator also has access to general server statistics, such as how many users exist, how many Workplaces are on the server, how much hard disk space these Workplaces take up (individually and in total) among other data, and can also add and remove Utilities on the server.
The standard user is unaware of the fact that they even have this role. A user may create Workplaces on a server on which he is registered as long as the Administrator has not changed this setting. When a user creates a Workplace they automatically become the Workplace's Project Manager.
A user may also be invited to a Workplace by the Project Manager (or otherwise – more later) of an existing Workplace.
Workplace roles can be very granular, allowing privileges to be set even within Utilities in a Workplace.
The default Workplace roles below are pre-configured according to the standard, preset Workplace as it is when it is created by any user on the server.
As I have already mentioned, a user who creates a Workplace on a Mira server automatically becomes the Workplace's Project Manager. The Project Manager is able to change everything applicable to the Workplace – he is able to change the roles of the Workplace's members, create new ones and configure existing ones (e.g. forbidding the users with the 'Member' role from inviting other users to the Workplace), he is able to add and remove Utilities on the Workplace, he has overriding power to add, alter and delete data from all of the Utilities and much more. However, a Project Manager cannot remove the Project Manager status from another Project Manager and can only step down if they have assigned one or more other Project Managers.
The majority of Workplace members will have this role. This is a very basic role which, by default, has privileges to add, alter and remove data from Utilities but not remove the data of others (particularly in the Files Utility, for this functionality is not as applicable to the Notes Utility, etc), but cannot invite other users to join the Workplace, cannot add or remove Utilities on the Workplace and cannot change any of the Workplace's settings. However, these privileges can be changed by the Project Manager as he wishes.
This is the most basic of the default roles. It allows users to read the lowest security level data on a Workplace but forbids them from writing or modifying any data on the Workplace.
A user may be invited to join a Workplace by a Project Manager or Member of a Workplace (depending on the configuration). The role that the user will be assigned upon entering the server is defined by the sender of the invitation. For example, the Project Manager, Joe Bloggs, could send an invitation to a registered user on the server, Michelle Banks, to join his Workplace as a Member. If she were to accept the invitation, she would be granted access to that Workplace with all the privileges of a Member as defined by Joe, the Project Manager of the Workplace.
Server roles are, by their very nature, embedded into the system.
Workplace role definitions are stored by the Directory module and enforced by the Security layer.
An implementation of the Bell-LaPadula model should be considered, or perhaps a semi-implementation whereby 'no write up' is enforced but 'write down' is allowed (may be useful if higher-level users need to interact with lower-level users, but produces confidentiality risks).
To be discussed at a later date, once all the core modules are functioning!
Not relevant for now.
Discussion