Access control
This feature is no longer planned to be implemented. A different approach to access control was chosen by Ari and implemented in March 2010.
At the moment access control is mostly per entity. That is, a user might have the right to edit milestones, but there is no level of control over which milestones they can edit. The only object level access currently implemented is on the project entity. While useful, this means it is not possible to have people included on a project who are able to view some tasks and not others. This proposal extends that implementation across other entities and makes it more flexible.
1. Access control is useless unless the user is able to quickly identify what level of access applies to every object. Otherwise embarrassing mistakes occur.
2. Systems with large numbers of users need to have a simple way to see which users are in each role. It is important that users are not given the wrong role and therefore elevated access by mistake. The current system makes it hard to review access across the entire database.
3. Extra choices and functionality cannot clutter the UI.
One option might be to allow setting access groups of users per project (eg. ‘staff’, ‘customer’, ‘public’) and then rights can be assigned with a popup per object (task, message, etc).
A background colour code (eg. yellow for private object, etc) could further enhance usability and give a clear indication of what objects are public and which are restricted.
- AccessLevel is no longer per project, but across the entire company. This means that access levels could be a simple sorted integer enumeration.
- When determining access, the AccessLevel table is not needed at all. Simply grab the [AccessLevel]id which is stored in the AccessibleObject superclass/interface. Then determine whether that id is in the list of access rights for the currently logged in user, against the appropriate entity.
- AccessLevel would still be used to colour the background of the accessibleObject to determine access level
The edit view is a quick mockup of the user interface for editing roles. Users can be given multiple roles and the concatenation of the highest level of access is given to them.
In this edit view, the role is given the ability to view tasks up to the level of ‘admin’, and read and edit ‘secret’ forums. This implies all lower level forums are also visible and editable.
This mockup is an example of a role editor form. It shows two access levels – Internal and External. Each access level has a number of permissions for different types of object in ClockingIT. If the box is checked, people with this role will be able to read, edit, comment or delete an object.
This mockup demonstrates how access levels could be used to allow Internal staff to have tasks, comments and even projects that external clients can’t see. For example, this could allow internal staff to have a discussion about a task that isn’t seen by external clients.
This mockup shows the changes to the task edit screen that would be needed to accomodate roles and access levels.
1. The comment field has an extra option – “Access Level”.
2. The task itself has an extra option too. This is in the Target section for now, but could be moved anywhere.
3. Comments in history are displayed as normal, but with an extra field for their access level. Background colours could also be used to clearly show Internal/External (public/private) comments.
Only access levels that the current user has access to are listed. If only one, then the dropdowns can probably be hidden completely.
This library might do a lot of what we need:
http://github.com/DocSavage/rails-authorization-plugin/tree/masterInvestigation is required to see how it fits our needs. Certainly using a library is preferable if it gives us what we need, since we save time and get an already tested piece of code.