User Groups

Cora, through configuration, provides several security and access features available to administrators so that all users are not daunted with the many features available in Cora.  Furthermore, Cora provides the administrators with a level of comfort that users cannot make changes to either the configuration or the data by accident. 

System access and data access is a vital step in the implementation of Cora and it is important to avoid giving users access to change system settings that affect other users.  It is also just as important to make sure users are not being given access to projects and data that they don’t need to have access to.  This means giving each user access to only the project(s) that they need to see, and then, defining which of the project(s) they actually update on those projects that they see. 

There are three key components of Cora that drive this, the user type as in license type, the system role assigned to the user, and then group access (or Project Access and matching Project Profile).  Note that there are further access settings available to administrators to add further granularity, however this article will focus on user groups. 

User Groups are very important as Groups can be used to assign users to a number of projects at once.

• For example, Group 1 is applied to Portfolio 1 with PROJECT OWNER profile.
• Group 1 is applied to Portfolio 2 with READ ACCESS only.
• User 1 is a member of Group 1- and therefore can see Portfolio 1 and edit, and can see Portfolio 2 but cannot edit it.  

You can have as many groups as you want, however to note, that groups are also shared with SCM for Resource Demands. Therefore, you may also want to use some form of naming conventions to describe what these groups are, for permissions. 

All Group names, Project Profile names, and the decision to use 1. Group to Projects; or 2. User to Projects or a combination thereof, is up to the administrator.  Therefore, no descriptors are provided in this article, however, the recommended practice is as follows:- 

1. Always use Groups assigned to projects.  The exception would be for only one user for every project to be added directly as a user and that is the Cora “admin” user (to provide support). 
2. Create groups with the Prefix of ACCESS: Group 1 so as to avoid confusing this with SCM groups.
3. Create the Groups down to a Programme Level, programmes are not expected to change too often and therefore new group creation or updates will be minimal. 
4. Create Project Profiles with the following convention, as in...
   1. Project Owner (System profile, cannot be changed)
   2. Level 1: Full Access to Project
   3. Level 2: Project Management Permissions
   4. Level 3: Project Support Permissions
   5. Level 4: Project Update Permissions
   6. Level 5: Read Only with Costs
   7. Level 5: Read Only no Costs
5. Assign groups to projects ONLY on the level of the Programme Structure that it is expected someone to make a change or update.  Don’t assign Groups to summary level, only to the Programme that the projects will belong to.

Whatever access is applied to the Project applies to them system wide; so for example if a user group does not have access to see Project A, people on that group will not be able to see Project A in the hierarchy, or any details about it in any widgets, reports or dashboards. – this also includes in the ADD PROJECT list.