BigPicture is now on ! Enjoy enterprise-grade Program & Portfolio Management, now fully integrated with monday.com boards and workspaces.  Try it now
March 25, 2024

#BigTip: Managing security roles to keep your boxes sealed tight

Security & Compliance
System Administration

BigPicture for Jira offers several layers of security to ensure no unauthorized person or malicious actor gains access to your precious initiatives.

On the first line of defense, there’s Appfire, the vendor behind BigPicture. We spare no effort to ensure your app meets the highest level of user data security and compliance requirements.

Further down, several in-app role-based security measures are in place. They guard data in your individual projects and entire portfolios (boxes) from being seen by non-permitted users.

In this post, you’ll learn how to assign and manage security roles in BigPicture.

What is a security role?

In the role-based security model, a security role represents a specific level of user privileges. It grants and limits a set of actions users or groups with specific roles can perform.

Using roles simplifies the process of adding, removing, and modifying permissions compared to individually assigning permissions to users. Security roles become especially helpful as the scale and complexity of your user base grow.

User roles and permissions also help prevent accidental or intentional changes some stakeholders could make.

Security roles across Jira and BigPicture

BigPicture respects Jira security settings.

When assigning security roles to Jira groups and users in BigPicture, Jira Admins should remember that those roles build on Jira settings.

What does it mean? It means that Jira groups/users need relevant security permissions from Jira and BigPicture to access the app and respective boxes.

Say a group of users can access a specific project in Jira. Without permission to access the app and a box with that project, they won’t be able to manage or view it in BigPicture.

Now consider the opposite case where users aren’t permitted to access a project in Jira but have access to BigPicture and a respective project box. In this scenario, the users will open a box but won’t see any project elements in it like tasks, milestones, etc. They’ll just see a blank box.

This dualistic security approach protects your Jira project from viewing by unauthorized people. Even if you add several Jira projects to the scope of one box, groups/users will see only tasks from a project they’re allowed to view in Jira.

Security role and permission management on different levels

In BigPicture, you can define user roles on the following levels:

  • Global level — this level determines access to BigPicture.

  • Box level — this level determines access to individual boxes and their sub-boxes.

Let’s go through them one by one.

Global security roles (Administration)

Global security roles and settings are part of the administration (business/HR) app configuration level. The three available global roles — App Admin, App Resource Admin, and App User — define permissions for the entire app. By assigning any of those roles, the Jira Admin actually decides who will access BigPicture and to what extent.

That’s why, even if someone has access to Jira and one or more projects, they won’t access BigPicture if their Jira Admin doesn’t grant them one of those roles.

Global security roles in BigPicture. You add Jira groups and users under respective roles to grant them access to specific areas within an app. Jira Admins are App Admins by default, even though they aren’t listed under the “App Admin” tab.

App Admin

An App Admin is like a Jira Admin, but only in BigPicture.

Jira Admins automatically become App Admins, so that they can access the app and grant other users respective privileges. Jira Admins can also assign the App Admin security role to a Jira group or user who isn’t a Jira Admin in their organization.

Just like Jira Admins, App Admins have full access to gadgets and relevant pages on every configuration level (app, administration, and box) in BigPicture — even though you won’t see their names listed under specific roles on those individual levels.

Apart from assigning user privileges, Jira Admin can also activate “Permissions for everyone” (toggle the switch located in the upper-left corner of the Administration page). When they activate that option, the global security roles become unavailable.

Because everyone with relevant Jira permissions automatically becomes an App Admin. So, the global roles become irrelevant.

The “Security permissions for everyone” option grants the App Admin role to everyone (depending on the user privileges in Jira).

 

This option is useful when, for example, you want everyone in your organization or team to click through the app to evaluate the trial version or learn to use it.

But, despite everyone’s access to everything, your Jira Admin can customize permissions on the business and/or box level to restrict Jira groups and users from accessing specific boxes or box types. (We’ll get to those security settings a bit further on.)

App User

The App User is the fundamental role that gives Jira users permission to access BigPicture.

App Users can see and access BigPicture. But this role doesn’t automatically give them access to projects or portfolios (boxes), even if they can access them in Jira.

 

Note: This role is for accessing the app only.

If you want a person or group to see the specific box with the Jira project, the Jira/App Admin will also need to grant them permission on the box level. Otherwise, they’ll see a blank page with no boxes in the Overview module (including the Overview gadget).

App Resource Admin

This security role is specifically designed to enable Jira groups/users to handle resource/HR-related tasks, like managing absences and holiday plans.

Because their role is limited to resources, App Resource Admins automatically gain access to the “Resources” subpage on the Administration page. If needed, Jira/App Admin can additionally grant them access to the individual box(es).

Resource Admin can access the “Administration > Resources” page and all its subsections (Individuals, Workload plans, Holiday plans, and Skills). The other pages, “Box types” and “Security,” are unavailable to them.

 

Box-level security roles

Boxes are the building blocks of the entire hierarchy that can hold portfolios, programs, and projects. They come with their individual role-based security settings that extend the privileges of the App Users.

Select the box you want to customize and go to the box configuration page (module switcher > “Configuration” from the drop-down list) > Security. You’ll see four box-level security roles: Box Admin, Box Editor, Box Viewer, and Sub-Box Creator.

The four security roles on the box level.

 

As with global roles, you can assign Jira groups and Jira users to any of those roles. No unauthorized person will be able to make any changes to your box settings or project.

Those roles protect your box and its contents — even in other modules. For example, when someone generates a report based on data from the box they’re not permitted to view, the report will not reveal that data to them. The report will show only the data their security settings allow them to see. 

Box Admin

Box Admins can access the box configuration page, enabling them to customize box settings in every aspect, including security settings. They can create sub-boxes (e.g., Iterations under an Agile project) and edit, delete, and resync the box.

Only a Jira/App Admin can assign Box Admins to individual boxes.

Moreover, Box Admins can limit permissions regarding project baselines to only the Box Admin role. This way, only Box Admins are allowed to create, edit, and delete baselines. They can extend baseline permissions to Box Viewers.

The upshot? You no longer need to worry that an unauthorized person will make changes to your base plan.

Box Editor

This security role allows users and groups to introduce changes to the project. They can add, edit, and delete tasks and change their scheduling mode and structure. They can do the same for dependencies and objectives.

If their Box Admin grants them permission, Box Editors can add, save, and delete baselines.

They can also switch between available column views and risk card views. But if they make any changes in the column view, they can’t save them.

Box Viewer

Users with this security role can’t introduce any changes to the box configuration or the project itself. They can’t create sub-boxes, either. Their only user privilege is to view the box in the “read-only” mode and export the view.

Sub-box Creator

Sub-box Creators can only create sub-boxes under a parent box.

From parents to children: Inheriting box security roles

Parent boxes can pass down their security settings to children using the inheritance mode in BigPicture. As a result, Box Admins, Box Editors, and Box Viewers of the parent box will have the same privileges in the sub-boxes. Only the role of the Sub-box Creator can’t be inherited.

Jira/App Admins can define inheritance mode for every box type on the “Administration” > “Box Types” page.

JiraApp Admins and Box Admins can customize box inheritance settings on the box type configuration page.

 

Sub-boxes always inherit the security settings from the upper box according to one of the two available modes:

  • Own with inherited — the sub-box will inherit groups and users with their security roles. You can add other people to the sub-box security roles.

  • Inherited only — the sub-box will inherit groups and users with their security roles. You can’t add other people to the sub-box security roles. (The “Security” tab” will become unavailable.)

As a result, whenever someone creates a new box using a box type (initiative template), their new box will automatically be set to one of those inheritance modes.

For example, your Box Admin assigned you the role of a Box Editor in an Agile project. When you create an iteration under your project, you’ll automatically become a Box Editor of the iteration as well. (But you won’t see your name under the Box Editor on the sub-box configuration page.)

Your colleagues who were assigned other roles (but not Sub-box Creators) will also carry over their roles to the subsequent sub-boxes.

Security roles in different box types (project templates)

Whenever you create a project, program, or portfolio using a box type, your initiative will also inherit the groups and users assigned to specific roles.

If your Jira/App Admin has defined a Box Admin for every template, you’ll also see them as a Box Admin in your project, program, or portfolio.

A Jira/App Admin can customize each box type, including its security settings. They can define inheritance mode and assign security roles to Jira groups and users. Your initiative will later inherit these groups and users.

Inheriting security roles from the Root box (Home)

You can take the inheritance feature one step higher — up to the root.

The root is the Home element — the parent element holding all the boxes in your organization’s entire hierarchy of portfolios, programs, and projects.

All the boxes under the root will inherit all the groups and users with their respective security roles. As a result, a person assigned to the role of, e.g., a Box Admin at the root level will automatically become a Box Admin to every box and sub-box created under the root.

In the screenshot shown, there’s one person under the Box Admin role on the root level. They’ll become Box Admin for every box anyone adds to the hierarchy.

 

That’s why you’ll want to exercise caution when assigning security roles to anyone at the root level — especially the Box Admin and Box Editor roles — because they’ll cascade down to every child box.

Sign up to try BigPicture for free

BigPicture helps you plan, build, and manage complex projects and portfolios, with two layers of in-app security roles that keep your BigPicture app and all the boxes safe from unauthorized users. By assigning the right roles to the right people, you can ensure that no unwanted person will edit or see your initiatives (or even parts of them).

Sign up for a 30-day free trial to see how BigPicture streamlines projects — no matter how big, complex, or unique they are. And join our live demo webinar to see why more than 20,000 PPMs and their teams trust our software to build their amazing products.