Set permissions

  Administration > Organization administration > Permissions >

Set permissions

Previous pageNext page Print this topic! Mail us feedback on this topic!

To set permissions select Admin in the Jama header, then select Permissions in the left column. From here you can access the organization and all projects, or navigate to an individual project with the Explorer Tree.

adminperspectivePermiss

Select the desired level in the project hierarchy from the list, then select Add permissions to add users and groups and define permissions for the project.

Permissions and Licenses

The license type assigned to a user may override the assigned permissions. If a user has a Read Only license, or a Floating License that is in Read Only mode, the user will not have the ability to manage a project or create/edit items.

A user with a Read Only license and Administrator permissions will continue to have access to Organizational configurations but she will not be able to Create/Edit items.

Inherited permissions

Permissions are inherited from higher levels in the Organization/project structure. For example, if you assign a group access at the Organization level, all projects, components, and sets within the Organization will inherit the permissions. The source of a group’s access is indicated by the Inherited column. When a row contains that value "True" and has a green highlight the group has received its permissions from a higher level.

"Override" provides the ability to adjust inherited permissions or remove access to a project, component, or set completely by unselecting all permissions.

"Remove" will perform different actions depending on the Inherited column’s setting. When the column indicates that the permissions are inherited "Remove" will revert the permissions back to the original inherited permissions. When the column indicates that the permissions are not inherited "Remove" will completely remove the group or user from a project or set.

Precedence of Assignments

Users can be assigned to one or more groups that may contain conflicting permissions. The system resolves potential conflicts by applying the highest level of access available to an assigned group or user.

Permissions Example

In this example, Jama contains four users: Frank, Rob, Danny, and Tony. Frank and Rob belong to the group Project Management while Danny belongs to Analysis. Tony belongs to two groups: Analysis and Quality Assurance.

permissionsexample1

All groups are assigned to the project level. The screenshot shows that the groups and permissions assigned at the project level have been inherited by the set of Test Cases.

Note: Permissions can also be granted at the component level (similar to permissions for a set). For simplicity, this example does not contain any components.

Tony belongs to two groups (Analysis and Quality Assurance) that have different permissions. Jama will give Tony the access available in the group with the higher level of permissions.

permissionsexample2

Here the group Analysis has its inherited permissions overridden to add the group’s ability to edit items within the set of Requirements. The change from the default access is indicated by the Inherited column value showing "false" and the removal of the row’s green highlight. To reset the group’s inherited permissions the administrator would select the "Remove" option.

permissionsexample3

This screenshot indicates that Tony has been added to the Risks Set individually with Create/Edit and Read permissions. The system will provide Tony with the highest level of permissions for the set providing him with the ability to Edit items in the Risks set even though both of his groups cannot.