Access roles for users of MSTS is a key part of the system. What data should the users see? What data should the users be able to modify? The solution adopted was the creation of 4 specific hierarchical roles, or sets of privileges:
One form in which the "default" role is used is within the summary screen. Only the users with a default role of Administrator may see the Admin: part of the sidebar. Also, not all the views are made available to everyone, such as User Action Items and Org Action Items. User and Org Action Items show all actions for a specific user or organization, so this is only seen by an Administrator.
The second way the roles are used is for the data within an action item. In the modification screen there are many fields that the user may modify. One could set up restrictions to each user based on their current level of access for the specified action. We do not have the rules in place for this, but the design does support these types of rules.
Consider the following scenario: Suppose Alice has a default role of Coordinator, and Bob has one of Administrator. Bob has created action 1 and made Alice a Participant within the action. What may a user with the level of Participant do to the data associated with this action? The answer to this question depends on the rules enforced on access. One way to do this would be to restrict Participants to modifying the description, resolution, and attaching of files.
Observers will only be able to observe, and an Administrator will be similar to a super-user. The rules will be for Participants and Coordinators. As time goes on, a different model may be needed, but the changes for a different model will not be difficult based on the design of the MSTS system.
The above describes our first implementation. After doing some more research with RBAC, we may implement a model such that the access will be administered with RBAC (ARBAC97). More will be said on this at a later time.