Contents: |
|---|
Multiple settings must be changed to fully benefit from BigPicture's security options. This article provides an overview of the configuration. For more details regarding any subject, follow the link to the dedicated page.
Limitations
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 users to see or edit an issue, they won't be able to do it using the App. If a user can access only 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 to access 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
For a detailed description, read Security (Administration).
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 a Box level)
App Admin
User Roles in Boxes
For a detailed description, read Security (Administration).
Box Viewer
Box Editor
Box Admin
Sub-Box Creator
Enabling Roles
BigPicture offers great flexibility when setting up roles, but you must first enable roles in general to utilize that. Make sure that you have enabled roles in the app's configuration.
Access to the App
Users need access to the App itself. The configuration is set in App Administration. Go to the App's drop-down at the top and choose 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
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.
Read more about Box Type settings.
Home (root) Box
In BigPicture 8, roles are always inherited from upper-level Boxes. It means that the 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 through 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.
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. Read more about Box Type settings.
Different settings options
App Admin vs. Home Box Viewer
You may want some people to be able to view all the boxes but not make changes to them. If you add a user as an 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 instance, 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 and can configure them, delete them, move them, etc. but won't be able to alter the App setup.
Inheritance Mode
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.
Example: the 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)..png?version=1&modificationDate=1725628421386&cacheVersion=1&api=v2&width=250&height=87)
Inherited only - you can't manually add users to the Box.
Program Increments and Iterations are Boxes, too. They are usually used to organize tasks within a given project Box. There is no need to add a separate set of users to those Boxes. Everyone who is meant to work on a project is added to the main project Box.
All those security options combined ensure you can grant users the access they need.
Match Security Roles
Security roles match
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 to the App
For example, Tom is a JIRA user.
He is an Administrator of the "Aggregation" JIRA Project.
There is a corresponding box in BigPicture. The Jira project has been added to its scope. However, Tom hasn't been granted any roles within that Box. As a result, when Tom logs in, he can't even see the Box within the App. Below, you can see the setup of the Box.
.png?version=1&modificationDate=1725628419769&cacheVersion=1&api=v2&width=760&height=217)
When Tom logs in, he can't find the Box.
.png?version=1&modificationDate=1725628419290&cacheVersion=1&api=v2&width=760&height=240)
Lack of access to Jira
Sarah is an App Admin. This means she can see and manage all the Boxes and configure the App itself. However, she can't do it if she tries to edit a Jira issue and doesn't have sufficient permissions within a Jira project. In other words, permissions within Jira limit possible user operations in the App.
For example, Sarah can't even browse the "Allocation Details" project in Jira. 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.
.png?version=2&modificationDate=1725628418681&cacheVersion=1&api=v2&width=760&height=200)
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 Insufficient JIRA Permissions in BigPicture/BigGantt.