Short guide to security settings (access and roles)
- Anna Ciepłota
- Agnieszka Sienkiewicz
- Marta Golab (Deactivated)
About security roles in BigPicture
Security roles define a specific set of user privileges. They control access to the app and boxes and determine the actions that users or groups with certain roles are allowed to perform.
By using roles, you can streamline the process of managing permissions, making it easier to add, remove, or modify access rights compared to assigning permissions individually to each user. This approach becomes particularly valuable as your user base grows in size and complexity.
Additionally, user roles and permissions help safeguard the app and boxes against unintended or unauthorized changes by stakeholders.
Jira permissions in BigPicture
Jira Admins have full and unrestricted access to all boxes and BigPicture.
BigPicture respects Jira security settings.
It means no user (or Jira group) can view and edit data in BigPicture they are not permitted to view and edit in a connected tool, such as Jira.
In case of insufficient security permissions in Jira, the data in BigPicture is grayed out.
If Jira permissions prevent users from editing an issue, they will not be able to edit it in BigPicture.
If a user can access only part of the issues in a box, the remaining part of the scope will not be visible to them. For example, if you add several Jira projects to the scope of one box, users will see only issues from a project they are allowed to view in Jira.
Available security roles
In BigPicture, you can assign roles on the app level (global roles determining access to the app) and on the box level (roles determining access to individual boxes and box types).
Global (app-level) security roles
Global roles are assigned and managed on the Administration > Security page.
App admin (just like Jira admin, app admins have full administrative access to the app and all boxes)
App user (app users can see and open the BigPicture app on their instances and access their profile but cannot view and edit individual boxes until they are assigned a relevant role on the box level)
Box-level security roles
Box roles are assigned and managed on the box configuration > Security page (roles for the individual boxes and specific box types are managed separately).
Box Viewer
Box Editor
Box Admin
Sub-Box Creator
To access BigPicture, users first need to be assigned one of the global security roles. Otherwise, they will have no access to particular boxes, even if they were granted relevant permissions on the box level and in Jira.
Security role inheritance
The Inheritance mode allows the sub-boxes to inherit (replicate) some of the parent box's configuration elements, including security settings. Security roles are always inherited from the upper-level boxes, starting with the root box.
For example, Program Increments (sub-boxes) inherit security roles from their direct parent (SAFe ART), from the Portfolio box, and from the root box.
Security roles inherited from the upper-level boxes are not listed on the Box Configuration > Security page. They can be viewed only on the Security page in the upper-level box where those security roles were added.
When you create a sub-box, the following roles are inherited:
Box Admin
Box Editor
Box Viewer
The role of the Sub-box Creator is not inherited, as it would potentially allow users to create sub-boxes they could not delete.
Inheritance mode on the root-box level
Security roles are always inherited from upper-level boxes. This means that the security roles granted in the root box apply to all boxes in the box hierarchy (boxes nested under the root box).
For example, if you are a Box Admin of the root box, you automatically become the Box Admin in all boxes in the box hierarchy.
Box type
A box type allows you to customize various default box settings, including security settings.
On the box configuration > Security page, a Box Admin can create a security role template by adding users to their respective roles. As a result, each time you create a new box of that type, the roles and users will be replicated in your new box.
Individual box
When a new box is created, a Box Admin can manage user and group access by adding or removing them from their assigned security roles within the box. They can do so on the box configuration > Security page.
Different settings options
Box Admin vs. Box Viewer (root box)
You may want some of the users or groups in your organization to be able to view all the boxes but not make changes to them.
By adding them as a Box Admin to the root box, they will gain full access to all boxes within the hierarchy and be able to make changes across them. That is not what you want.
Instead, add them to the Box Viewer role in the root box. This way, they will be able to view all the boxes in the box hierarchy and the contents of those boxes, but they will not be permitted to edit them.
App Admin vs. Box Admin (root box)
You might want someone to have admin access to all boxes in your organization without allowing them to edit app settings.
To enable someone to perform all box-related operations without modifying the app configuration, assign them the Box Admin role for the root box. This will give them full visibility and control over all boxes, including the ability to configure, delete, and move them, while preventing any changes to the app setup itself.
Inheritance mode (box types)
Sub-boxes always inherit security roles from their parents but depend on the following inheritance settings of the box type:
Own with inherited: A sub-box inherits roles from the upper-level boxes, but Admins can assign additional users and roles within that particular box.
Example
A Portfolio Manager needs access to multiple projects stored in a Portfolio box. An App Admin (or another Box Admin) can assign them a Box Admin role in the Portfolio box.
As a result, the Portfolio Manager becomes the Admin of all the projects and initiatives under the Portfolio box. When a Project Manager creates a new project under the Portfolio box, the new box automatically inherits the Portfolio Manager as the Box Admin.
Box Admins can add new users and groups and remove the existing ones in the individual boxes that belong to the Portfolio box. For instance, they can grant a Box Editor permissions to a user or group but only in a specific box (“Ongoing agile project” in the screenshots below).
In such a case, a Box Editor in the “Ongoing agile project” is the box’s own, non-inherited editor. For that reason, their role will not be inherited by another project box in the portfolio, like the “Smart house” project box.
Inherited only: - Admins cannot add more users to their respective roles directly in a box.
Example
Program Increments and Iterations boxes are typically used to organize tasks within the scope of the parent box. There is no need to add a separate set of users to those boxes. That’s because everyone who is meant to work on a project is already added to the parent box.
Assign and match security roles
Security roles should match. If someone can edit a project in Jira, make sure they can also edit a box with a corresponding project in BigPicture. Likewise, if you assigned a user to manage a box in BigPicture as Box Editor, check if they also have the required permissions in Jira.
User was granted the required permissions in Jira but not in BigPicture’s box
Tom Anderson, in this example, is a Jira user.
He is an Administrator of the "Aggregation" project in Jira.
In BigPicture, there is a box corresponding to the “Aggregation” project. The Jira project has been added to the box's scope.
Although Tom is an App User (he can access BigPicture), he was not granted any roles in the “Aggregation” box (or any other box). As a result, when he logs in to BigPicture, he will not see any box in the Overview module on the root box level.
User was granted the required permissions in BigPicture but not in Jira
In the second case, the Jira Admin assigned Tom Anderson an App Admin role so that he could see and manage all the boxes in the organization and configure BigPicture.
However, although Tom can access and configure the settings of any box in the box hierarchy, he cannot edit Jira issues. That is because Tom does not have sufficient permissions in the corresponding Jira projects. In other words, Jira security permissions limit Tom’s actions in BigPicture.
BigPicture cloud
Permissions
If you see a message in Jira about insufficient permissions while trying to access BigPicture or BigGantt for Jira Cloud, follow the steps described on the following page: Insufficient JIRA permissions in BigPicture/BigGantt.