In general, you can find information on Security settings on the following pages:
- Box Types - this page contains information on configuring the default Security settings that work as a template when you create new Boxes and the Inheritance mode.
- Global Roles - this page explains App Administration settings and how access to the App is granted to, for example, Jira users.
- Box configuration - this page explains what roles are available within the App and how to change them for an individual Box.
- Configuration of the App - this page gives you information on how to activate/deactivate the use of roles within the App.
- Security - You are on this page - it explains the impact of setting up security Roles for the Home (root) Box and lists available roles.
Security roles are always inherited from upper-level Boxes - therefore, security roles defined in the Home (root) Box function as a default for all Boxes in the hierarchy. If someone is a Box Admin of the Home (root) Box, they automatically have the same permissions in all sub-Boxes through the hierarchy.
Security roles are always inherited from upper-level Boxes (starting with the Root Box). This way, every time you create a new Box, it will inherit the security roles - you do not need to assign them from scratch.
When you create sub-Boxes, the following roles are inherited:
- Box Admin
- Box Editor
- Box Viewer
The sub-Box Creator role is not inherited, as it would potentially allow users to create sub-Boxes they can't delete. To find out more about the sub-Box creator role, scroll down to the relevant section of this page.
For example, if there is a "New Hybrid Project" Box nested under the root:
All Boxes under "New Hybrid Project" will inherit the roles from it - that includes Iterations and Hybrid Stages (a user who is an Editor in the "New Hybrid Project" will also be an Editor in Hybrid Stages and Iterations)Click here to expand...
All roles set up for the Home (root) Box will be inherited by the "New Hybrid Project" and its sub-BoxesClick here to expand...
You can't make a Box private to prevent users from upper-level Boxes from having access.
Inherited roles are not listed in Box Configuration > Security. Only roles assigned to the Box are listed - users can be manually added by an Admin if the Inheritance mode allows it. Additionally, when a new Box is created, users are granted roles based on Box Type settings.
A Box Lead is not a security role. This setting doesn't automatically grant any permissions. For a user to have access to a Box, they must also be assigned some security role within a given Box.
A Box Lead assignment enables the use of a "My Boxes" filter in the Overview of the application.
When you click “My Boxes,” only the Boxes in which you are the “Box Lead” will be listed. Boxes in which you are an admin/viewer/editor/sub-Box creator will not be displayed:
App and Jira administrators have access to all existing Boxes. Users who lack access to a particular Box or, in other words, are not assigned to any security role, will not see the Box in the Overview module an in the Box switcher unless a user has access to a sub-Box (but not to the upper-level Box), the upper-level Box will be displayed as a greyed out row (without links) to show the Box structure properly:
Roles can be assigned to individual users or entire Jira user groups.
Users or groups with this role have all the permissions granted, except for accessing the App's Administration page.
Sub-Boxes inherit the Box Admin role.
As a Box Admin, you can:
- administer the Box (access the Box configuration section)
- create Boxes and sub-Boxes (child Boxes)
- edit the Box (for example, change the Box status and the Box content)
- delete the Box
- do a Re-Sync of a Box
Besides editing the Box content as described in the Box editor role, you can change the Box configuration settings as a Box Admin.
Due to the Inheritance mode, some Box configuration settings might be disabled or hidden. To change the inheritance mode.
Sub-Boxes inherit this role. With this role, you can:
- add, edit and delete Tasks
- manually change the Task structure (hierarchy)
- change the period mode of tasks (including Locked tasks)
- add, edit and delete objectives
- add, edit and delete task dependencies
- switch between different available risk card views
- switch between available column views
- modify current column view (can make temporary changes to what they see on the screen, but can't save the new setup and make permanent changes to existing column view configurations)
This role is inherited when you create sub-Boxes. Users or groups with this role will not have access to the Box configuration. However, they can view the Box content in a 'read-only' way and use the export functionality.
Use it to, for example, let users create Project Boxes as Sub-Box to a Portfolio Box.
- Only a Box admin can create a sub-Box using a Box type with "Inherited only" security mode.
- You cannot create a sub-Box if later on you won't be able to delete it.
For example, Angela has two roles in the AGILE project Box (editor + sub-Box creator). She tries to add an Iteration - she can't do it if the security mode of the "Iteration" Box type is set up as "Inherited only." Adding a sub-Box with "Inherited only" security mode means no new roles are granted for a sub-Box (a sub-Box admin can't be added during the creation process). She wouldn't be able to delete a sub-Box. Therefore, she cannot create a sub-Box.
If the "Iteration" Box type has the "Own with Inherited" security mode selected, she can create a sub-Box, because she will automatically become its admin. She can later delete it.
When Tom, a Box admin of the AGILE Box, tries to create a sub-Box, the security mode of the "Iteration" Box type doesn't restrict him. Even if a new Iteration will have the "Inherited only" mode selected for security, he can always delete a sub-Box, because he is the AGILE Box admin, which automatically makes him a sub-Box admin.
You can grant users a sub-Box creator role on the Home (root) Box level. As a result, they will be able to create their own Project Boxes but won't be able to access or edit other Boxes nested in the Home Box. Sub-Box creators can then use Box types with the "Own with inherited" security mode to set up new Boxes. Then, when they create a Box, they automatically become its admin.
The Resource Admin role is effectively an extended App User role, which means that such a user:
- has basic access to the App (can access their user profile and sees the App dropdown in the header)
- can access Boxes based on individual Box security settings - does not receive access to all Boxes automatically like App Admin
- additionally is allowed to administer resource-related global configuration (Administration>Resources page with all subpages, no access to Box types, Security)
- cannot access App configuration, unless the User is hostplatform Admin at the same time.