Roles and user management

To interact (create, edit, view, delete) with a work item in Shibumi, you must be assigned a role that has permission to access the work item.

Overview

Permissions are inherited downwards, that is, a user assigned to a role on a work item will have access to the work item and all the descendent work items. The default permission (access level) that the user has on the work item is defined by the role assigned. Each role is assigned to one of three access levels: admin, edit, or view.

Five out-of-the-box roles are available on every template. The following table identifies these role and their associated access levels.

Role Access level Manage roles Read Edit Create Copy Move Delete
Owner, Sponsor, Admin Admin ✓ ✓ ✓ ✓ ✓ ✓ ✓
Collaborator Edit ✓ ✓ ✓ ✓ ✓ – –
Viewer View – ✓ – – – – –

Your solution can have additional custom roles. When creating the custom role, the app admin will select an access level for it.

For roles with the edit access level, when the app admin enables the role on a template, that is the role will be available on instances of the template, they can further define whether the role can manage role assignments. If the ability to manage roles is allowed, any user with this role will be able to assign users to any roles with access level of edit or view. They will not be able to manage assignments to admin access level roles.

You can see the access level of each role on the Roles tab of either the template or the app.

Note:
  • The access level defines the default permission for the role on a work item. With additional configuration logic; however, the app admin can further restrict permissions. For example, the app admin can define tab visibility logic allowing only users holding the finance team role to see the finance tab. Even though users hold other roles with admin access level, if they do not hold the finance team role, they will not see the tab.
  • Roles are multi-user. There is not a limit on the number of users that can be assigned to a role.
  • Users can be assigned to multiple roles on a single work item.
  • When a user holds multiple roles, the default access level for the user will be the highest level of their assigned roles. This logic applies to inherited roles as well. For example, if a user is assigned to an admin access level role at the program level and then assigned to an edit access level role to a descendent project within the program, the default access level for the user on the project will be the admin access level.

Participant window

The Participant window enables the management of role assignments on a work item.

Assign users to roles
  1. Click the avatar icons to open the Participant Window.

    assign users to roles
  2. Enter the email address of the user you want to add.
    • For first-time users, Shibumi will email an invitation to the user to set up an account and log in.
    • For existing users, when you start typing the user’s name or email, it will automatically complete.
  3. Select one or more roles for the user.

    Roles that have been enabled on the template will be available in the drop-down list.

  4. Select the blue Add option to add the user to the item.
Note:
  • Pressing down the command or ctrl key on your device (Mac vs. PC) will allow you to select multiple roles without the drop-down closing.
  • Visible To includes all users that do not directly have a role on the work item but that have inherited permissions to see the work item from an ancestor work item role assignment.

    Permissions are inherited to descendent work items. For example, if a user is assigned to a role on a program that includes five projects, the user will have access to the program and all of the projects.

  • Users can also be assigned from a role column included on a list, view, or table or from a role field on an edit or create form.
Manage role assignments
To manage role assignments for a user, open the Participantwindow and click the user name. A floating menu is displayed with three options: Manage, Replace All, Remove All.
Note: If you do not have a role with the ability to manage roles, you will not see the floating menu.
  • Manage

    manage roles
    • The Manage Roles window displays all roles enabled for the work item. The roles provided to the user will be selected.
    • Select or deselect roles to add or remove the user to or from roles on the work item and click Save.
  • Replace All
    • The Replace All option replaces a user in all roles they hold on the current work item as well as on any roles they hold on descendant work items.
    • On the window, select another user to replace the current one in all roles. Click Replace.
  • Remove All

    The Remove All option removes the user from all roles on the current work item. It does not remove the user from roles provided for descendant items. A dialog box will ask you to confirm the removal. Click Remove.

Permissions

Permissions are inherited downwards. For example, a user assigned to an admin access level role on a program work item will have admin access to the program as well as on all descendent project work items.

Conversely, permissions are never inherited upwards. No users will have access to the items above the highest level to which they are directly assigned a role.

For example, in the following image, Jane Doe has been assigned as collaborator on the *IT workstream within the digital transformation program. Jane has access to all of the descendent projects and milestones within the workstream. When Jane opens the business logic development milestone, the breadcrumb trail above the title of the milestone will not extend past the *IT workstream level.
Note: The (unavailable) app name is listed to the left of the highest level the user has access to.

permissions

Additional role functionality

Owner role: Owner is an out-of-the-box, admin access level role. The creator of a work item will automatically be assigned to the owner role in the follow scenarios:

  • The work item is created from a List section. For these sections, the owner field cannot be included on the Add Item dialog box so the creator is assigned by default.
  • The work item is created using Bulk Edit on a List section and the owner role is not included on the bulk edit form or is on the form but is left empty.
  • The work item is created through a create form or sidebar create and the owner role is not included on the form or is on the form but is left empty.

An owner is not automatically assigned for work items created through the following methods, but can still be assigned manually:

  • Create work item business rule (can use an Assign Role Action to assign owner, if required)
  • Import or export section (can include owner as a column to assign owner, if required)
  • Child work items populated from a template
  • Dashboards or presentations that came from a template
  • The GraphQL API

Placeholders or open resources

  • Shibumi provides the ability to define a placeholder role. This is referred to as an open resource and can be defined in the Participant window for any work item in the solution.

    It allows for a placeholder role assignment on work items without assigning a user. Open resources are often used when the details for a work items are not yet ready to be shared with all users but it is valuable to understand which roles will be participating.

  • Until the open resource is filled with values, it will be displayed with a gray background.
  • To enter values in open resource, click the Open Resource, select the Assign All option, and select the user that will be assigned. This will apply to all roles the placeholder has on the current item as well as on all descendant items.

open resources

Note: One common application of the open resource capability is for the program admin to assign roles to the open resource throughout the program. Only when the solution is fully defined, assign a user to the open resource. All items in the program assigned to the open resource are then assigned to the designated user and summarized into a single email invitation.