Security Configuration

Contents: 1 Security and access 2 Inheritance of Roles 3 Default Box Type Roles 4 Restricting access 5 Security roles 5.1 Box Admin 5.2 Box Editor 5.3 Box Viewer 5.4 Sub-Box Creator 5.5 Resource Admin

Contents: 1 Security and access 2 Inheritance of Roles 3 Default Box Type Roles 4 Restricting access 5 Security roles 5.1 Box Admin 5.2 Box Editor 5.3 Box Viewer 5.4 Sub-Box Creator 5.5 Resource Admin

In general, information on Security settings can be found 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 - you are on this page. It explains the roles available within the App and how to change them for an individual Box.
Security (Overview module) - this page explains the impact of setting up security Roles for the Home (root) Box and lists available roles.

On top of the Jira permissions and security settings, which are always respected by the App, you can grant security roles to individual users or to Jira user groups (creating groups requires Jira admin permissions). The roles can be defined for each Box separately or inherited automatically when you create sub-level Boxes.

Security and access

The Box security settings can be configured only when the 'Default Roles' option is selected in the App's configuration. Otherwise, all users will be granted the highest level permissions.

To change the assigned security roles of a given Box, go to Box Configuration> Security.

Only a user with a minimum Box admin security role can access and manage the Box configuration.

This configuration page will not be visible if the inheritance mode is set to "Inherited only" in the App's administration > Box types > Security.

The Inheritance mode depends on a Box type. When creating a new Box, you must select a type - security settings are copied, including the Inheritance mode and the role template.

Inheritance of Roles

Security roles are always inherited from the upper-level Boxes, starting from the Root Box. This way, every time you create a new Box, it will inherit the Security Roles so that 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 is not inherited, as it would allow users to create sub-Boxes they can't delete. To learn more about the sub-Box creator role, scroll down to the relevant section of this page.

User roles inherited from upper-level boxes are not listed in Box Configuration > Security. They can be viewed only at the upper level.

Default Box Type Roles

When you create a new Box, security roles are copied from a Box-type role template. In the settings of each Box type, you can assign roles to users. Then, when you create a new Box, those user roles are copied. Users added based on the template are visible in the Box Configuration > Security section.

You can assign default roles in the Box type configuration to save time when assigning the Security Roles.

Restricting access

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 and 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:

Security roles

Roles can be assigned to individual users or entire Jira user groups.

Info: The "Access Status" column can display two statuses:

"Granted" - informs that a role has been assigned to a user successfully.
"No access" - informs that a role has been assigned to a user, but global App permissions are missing. The user doesn't have general access to the App. To grant global permissions to the user, go to Administration > Security and add the user to AppAdmin or AppUser global permissions.

"Access Status" is shown for added users, not for groups.

Box Admin

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 Resynchronization 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.

Info: Due to the Inheritance mode, some Box configuration settings might be turned off or hidden. To change the inheritance mode.

Box Editor

Sub-Boxes inherit this role. With this role, you can:

add, edit, and delete Tasks
manually change the Task structure (hierarchy)
change the scheduling 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 open 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)

Box Viewer

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.

Sub-Box Creator

Use it to, for example, let users create Project Boxes as Sub-Box to a Portfolio Box.

Info: This role is not inherited.

Constraints:

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 you won't be able to delete it later.

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 has the "Inherited only" mode selected for security, he can permanently delete a sub-Box because he is the AGILE Box admin, automatically making him a sub-Box admin.

Recommended use:

You can grant users a sub-Box creator role on the Home (root) Box level. As a result, they can 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.

Resource 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 see 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 simultaneously.