Permissions in Jama are customizable to fit your organization’s needs; they can be tailored at as large of a scale as the organization level, down to a specific set within a project. You can set specific permissions for one user, or create a User Group with its own permissions. However, depending on the size of your Jama user base it will likely make more sense to set up User Groups in a strategic fashion if the user count will grow over time. A common misconception is that license types come with pre-determined permissions, which is not the case. All permissions must be assigned manually and the license types are a way to categorize user ability levels in the Jama environment. Users and User groups
In order to set the permissions for both Users and User Groups, you will need to be a Jama Administrator. Under Permissions
, you will see a tree of your Organization's Jama instance, called the Project Selector
, and all the projects currently active within it. From here, you can select the organization, an individual project, or even expand a project to select a specific component or set.
To the right of the Project Selector
will be the existing permissions for the project, component, or set you have selected. There will also be an option to add permissions allowing another user or user group to be configured with specific permissions levels. Organization vs. Project
There are two types of levels at which permissions can be set: Organization and Project. The permissions that are set at the Organization level will be available to all projects and have inherited project permissions based on the permission configuration set at the Organization level. Either the Organization Administrator or the associated Project Manager can override the inherited permissions per project.
The screenshot below depicts the User Group permissions that have been set at the Organization level.
The groups that are depicted here will be present in each project within the Organization with the same inherited permission levels. However, you can create a group at the Organization level. This gives you the ability to remove it then pick and choose which project to assign the User Group to, if needed.
Alternatively, if you want to create a project specific group you can access the 'Manage All Projects
' section > Project Permissions
> Add Permissions
> New Group
. The Project Manager also has the ability to do this through the Configure Project
menu (shown below).
The Organization Administrator or Project Manager can set permissions as granular as per set. For example, the Administrator may need to restrict Create/Edit capabilities on a certain set in a project that they do not want edited. They can even remove all permissions on a set so the user(s) cannot even see the set in the associated project. Columns Inherited:
Permissions for Users and User Groups 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. When a row contains the value "True" and has a green highlight, the group has received its permissions from a higher level. It is possible to override these inherited permissions by clicking Override
to the right of the user or group. Manage Project:
Users with these permissions can manage permissions for the project, as well as create and edit items. Project Managers cannot add new users to their projects. Create/Edit:
Users with these permissions will be able to create and edit items within the project. Keep in mind that only users with Creator License types can create and edit. Read:
Users with "Read" permissions can only view items. Actions:
- Override: If the group or user has inherited permissions from the Organization level, Override will give you the option to customize those permissions for the project. By Overriding, it is possible to remove permissions entirely.
- Modify: Edits the permissions for the group or user.
- Remove: Will remove the user or user group permissions entirely for that project, set, or folder.
NOTE: if a user is part of multiple user groups with conflicting permissions, the user will be given the highest permissions that are set. Setting Permissions through Root
Permissions and User settings can also be set from the Root menu. These are accessible under the Users
tab in the Root menu.
It is also possible to enable or disable the ability to allow your Project Managers to add groups and set permissions to the projects they manage. This can be found under the System Properties
tab, near the bottom of the page. By default, this setting is turned on. Permissions and Attachments
It is important to note that while items within sets fall under the permission rules of the set, any attachments made to those items will not be included in those permissions. Attachments can still be accessed by outside users by two ways; the first, through the Attachments Widget –
– and the second, through the "link" button while editing a rich text field.
The Attachments Widget can be hidden from an item type. To do this you will need to be a Jama Administrator. Under the Admin
tab, click on Item Types
. Select the item type you wish to remove the attachment widgets from, and click Edit
. This will open a pop-up window where you can removeAttachments
from the Active Widgets
column. It is important to keep in mind that if you do choose to make the Attachments Widget inactive, users can still access attachments through editing an item and creating a link. Why do attachments not inherit the permissions of the item?
Attachments in Jama are seen as individual items, and as such are stored at the project level. It is not recommended to store classified documents as an attachment in Jama since they do not inherit the permission level of the item type to which they are attached. Instead, sensitive documents should be made into an item in Jama so proper permissions can be set. NOTE:
Attachments are indexed so their content is searchable within Jama. Please take note if attaching documents containing sensitive information.#administration