Short guide to security settings (access and roles)

To fully benefit from the available security options, multiple settings have to be changed. This article is just an overview of the configuration. To get more details regarding any subject, follow a link to the dedicated page.

Keep in mind; no user can ever see anything they can't see in the connected tool (such as Jira) - those items will be greyed out. If Jira permissions don't allow a user to see or edit an issue, they won't be able to do it using the App. If a user has access only to half the issues in a Box/Program, the other half can't be viewed. This means there is no possibility of a person accidentally accessing or editing items they don't already have permission for in the external tool (such as Jira).

JIRA Admins always have full, unrestricted access to all Boxes and the App.

Available User Security Roles

App Administration

You can find the detailed description here.

App User (has access to the App - sees the App dropdown at the top. This doesn't translate into actual access to Boxes/Programs! User security roles have to be specified on Box level)
App Admin

User Roles in Boxes

You can find the detailed description here.

Box Viewer
Box Editor
Box Admin
sub-Box Creator

Enabling Roles

The App gives you a lot of flexibility when it comes to setting up roles, but to utilize that, you have to first enable the use of roles in general. Make sure that you have enabled the use of roles in the configuration of the App.

Access to the App

Users need access to the App itself. This is configured in App Administration (App's drop-down at the top > Administration).

There are only two types of App access:

App Admin (gets full Administrative access to the App and all Boxes)
App User (sees the App drop-down in the header and can access their own profile, but to see and edit Boxes, they must be assigned additional roles within Box hierarchy)

If a user has not been added to the App itself, they won't be able to access it. Even if they have been assigned roles within individual Boxes.

Access to Boxes

Role Inheritance

In BigPicture 8, roles are always inherited from upper-level Boxes.

For example, Program Increments (in the picture below) inherit roles from their direct parent ("OMEGA"), from the "Portfolio" Box, and from the "Home" (root) Box.

User roles inherited from upper-level boxes are not listed in Box Configuration > Security. They can be viewed only at the upper-level of the hierarchy, in the Box where they have been added.

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 potentially allow users to create sub-Boxes they can't delete.

In general, roles are always inherited, but depending on the Box type:

Own with inherited - a Box inherits roles from upper-level Boxes, but users can also be granted roles within that particular Box.
Inherited only - you can't manually add users to the Box.

Home (root) Box

In BigPicture 8, roles are always inherited from upper-level Boxes - therefore, security roles granted in the Home (root) Box apply to all sub-Boxes in the hierarchy (all sub-Boxes and their children nested under the Home Box). For example, if someone is a Box Admin of the Home (root) Box, they automatically have the same permissions in all sub-Boxes thought the hierarchy.

If you want to grant a user the same role in all Boxes, assign it within the Home (root) Box. It will be inherited throughout the Box hierarchy.

BigPicture-BigPicture-demo (21).png

Individual Box

To change the assigned security roles within a given Box, go to Box configuration > Security.

Box Type

In BigPicture 8, we have introduced Box types - a Box type is akin to a template; it allows you to define various default Box settings, including security roles.

In Box Type settings, you can create a security role template (grant users various roles). Then, each time you create a new Box of that type, the roles are copied from the template into your new Box. A Box Admin can later manage those users in Box Configuration.

Why this many settings options?

App Admin vs. Home Box Viewer

You may want some people to be able to view all the Boxes, but not to be able to make changes to them. If you add a user as App Admin, they have full access to everything. But, if you add someone as a Viewer to the "Home" (root) Box, they can see all the Boxes and their contents but can't edit them.

App Admin vs. Box Admin

You may also want someone to have Admin access to all Boxes, but not to the App itself. An App admin can, for example, edit Box types. If you want a person to be able to carry out all possible operations on Boxes but not change the App setup itself, making them a Box Admin of the "Home" (root) Box accomplishes exactly that. A user will see all the Boxes, can configure them, delete them, move them, etc. but won't be able to alter the App setup.

Inheritance Mode

In general, roles are always inherited, but depending on the Box type:

Own with inherited - a Box inherits roles from upper-level Boxes, but users can also be granted roles within that particular Box.
A good example of an implementation of this mode would be a Project Box within a Portfolio. A Manager may need access to multiple projects. You can make them an Admin of a Portfolio - this way, they automatically get admin access to all Boxes within it. In the Portfolio, you can have individual Project Boxes - team members and Project Leads are added to their respective Project Boxes. Those Project Boxes allow you to grant roles within them - if someone is an Editor in "OMEGA" Box, they don't have access to other same level Boxes ("ALFA" and "Implementation Project" in the example below),
Inherited only - you can't manually add users to the Box.
Keep in mind, Program Increments and Iterations are Boxes too. Usually, they are used to organize tasks within a given project Box. There is no need for a separate set of users to be added to those Boxes. Everyone that is meant to work on a project is added to the main project Box.

All those security options combined make sure you can grant users exactly the access they need.

Matching Security Roles

In general, remember that security roles should match. If someone can edit a JIRA project, make sure they are also able to edit a corresponding Box (program) in BigPicture.

Lack of access within the App

For example, Tom is a JIRA user.

He is an Administrator of the "Aggregation" JIRA Project.

In BigPicture, there is a corresponding Box. The JIRA project has been added to its scope. However, Tom hasn't been granted any roles within that Box. Therefore, when Tom logs in, he can't even see the Box within the App.

Below, you can see the setup of the Box.

When Tom logs in, he can't find the Box.

Lack of access in JIRA

Sarah is an App Admin. This means she can see and manage all the Boxes and configure the App itself. However, if she tries to edit a JIRA issue and she doesn't have sufficient permissions within a JIRA project, she can't do it. In other words, permissions within JIRA limit possible user operations in the App.

For example, in JIRA, Sarah can't even browse the "Allocation Details" project. Because she is an App Admin, she can access a corresponding "Allocation Details" Box in BigPicture (and configure it); however, she can't view the tasks. She doesn't have the necessary JIRA permissions, so she can't see them in the App.

Cloud version of the App

Permissions

If you see the following message whilst trying to access either BigGantt or BigPicture for Jira Cloud, follow the steps described in this article.