Delegation and user visibility updates
Jama has introduced several updates coming out in 8.60 & 8.61 to help organizations delegate administrative responsibilities and further control visibility of users, groups and projects.
New Administration Roles
Previously, the organization admin role was required to perform most administrative functions. This limitation resulted in either overwhelming the organization admins with requests or providing the role to more users than desired. To remedy this Jama has introduced several new roles.
- User admin*
- Process admin*
- Add project*
* available to select customers in 8.60
The goal of each new role is to provide access to specific responsibilities allowing an organization to delegate as appropriate.
Please note: Organization admin permissions cannot be overridden. In the past there was the appearance of controlling an org admin’s access, but that user could still see all projects and content and if they wanted, give themselves access. We believe we can remove some of the confusion around org admins with the addition of the new roles and ability to decrease the need for a large group of org admins. No updates or overrides configured in the past were removed. We do recommend removing these going forward as your organization adopts the new admin roles.
A group or user assigned only the user admin role will be limited to managing organization groups and user details/licenses. While this user will have access to all organization groups and users, they will not have the ability to see any projects or assign permissions.
Some of you may be asking “What good is a user admin that can’t assign permissions?” To answer this question, we have provided the ability to combine the user role with the project admin to control which projects this user can see and adjust permissions.
In the example below, the user has been assigned the user admin role and the project admin role for the Standard Frameworks folder. This user does not have visibility into any projects located outside of this folder but can add a user to Connect and provide them access to projects in this folder. Checking the Project role at the organization level for the user admin will give the group default access to all projects.
Only the project groups where the user admin is a project admin will be visible when viewing the list of all system users.
The process admin is limited to working with areas focused on how data in Connect is managed.
Similar to the user admin role, the process admin will not have access to projects where they are not configured as a project admin. The first example below shows what a process admin with no project admin rights would see when viewing relationship rules. If they attempt to remove the rule the system will inform the user that there are projects assigned to the rule and it cannot be removed.
In the next example, the process admin has been assigned project admin rights to the folder holding a group of sample projects. They can now see the projects assigned to the rule and adjust those accordingly.
As the name states, this role is to provide users with the ability to create a new project. We recognize that it may be rare when a new project is created without copying a template or previous project. To remedy this and to ensure that there is control over which projects can be seen and duplicated, we’ve also combined this option with project admin rights. Those users will have the ability to duplicate any project where they are the project admin. Archiving and deletion continue to be the responsibility of org admins.
This role is specific to developers that may need to upload or adjust reports but shouldn’t have access to any other administrative areas. To keep with the theme of not exposing projects, the report admin can only apply the new report to projects where they have access when not uploading the report for the organization.
User and group visibility and additional settings – 8.61
There are several ways of accessing users and groups when editing items, notifying others to an update or commenting. Users have noted there were inconsistencies in who was shown in these options as well as situations where there was a desire to control options for additional security. The primary goal was to consistently only provide lists of users and groups that aligned with the focus project’s permissions.
Signer roles restricted to selected project
Small update was made to remove any projects groups that are outside of the project content being reviewed. Organization groups will continue being displayed.
Project admin access to all users
One new setting we were asked to provide is to allow project admins full access to all users and organization groups so they can add these users to their projects. We created the setting separately from the new user admin role as many organizations do not want their project admins accessing user licensing, only adding existing users into their project.
Access to all users and organization groups will not be default behavior, and org admin can provide the option via a new setting on the Admin -> Organization Details page.
New comments from global Stream disabled
The global Stream tab is helpful for finding and reviewing questions and comments from different projects in one place. It has not proven to be helpful as a place to create new comments and was considered an issue for security as all users and groups are accessible via @ mention.
To address the security issue without immediately removing the option for all that may find this helpful we’ve introduced a new setting. New comments from the global Stream will not be default behavior however, replies to comments will still be available. Please note the @ mention users in replies will be restricted to main comment’s project the same as if the user was replying to the comment from within the project.
An org admin can turn new comments back on via a new setting on the Admin -> Stream page.
We added new restrictions to existing REST endpoints that are specific to accessing users and groups.
GET users/ & GET usergroups/ will both require the requestor to be an organization admin or user admin as both endpoints provide full access to all users in Connect. A project admin will be able to access their groups and users by providing a project ID.
Endpoints that include a specific user or group (e.g. GET usergroups/id) will check that the requestor shares project permissions with the requested user or group prior to retrieving data.