Skip to main content
Feature Guides

User Permissions

Introduction

The User Permission system replaces the default Brightspot Users & Roles system.

In default Brightspot, a CMS user (AKA ToolUser) is given a role, which has permissions on it. These permissions define which sites, areas, UI, and types they have access to.

This system has some limitations:

  • A user can only have 1 role
  • If multiple users have slight differences in a role, a brand new role must be published
  • Only super admins can create roles, and can assign whatever permissions they desire to any user

The User Permission system aims to fix those, plus provide additional capability. Some improvements include:

  • Reduce role permutations by breaking roles into permissions
  • Different permissions for different sites
  • Add the ability to only assign permissions that you have
  • The ability to manage other users and only modify users you manage

These improvements are done using various subsystems, which are all detailed below.

Site Hierarchies

The site hierarchy system defines how the organization is structured. For example, here is a small hierarchy representing the BYU organization:

Terms

  • Site Group: A grouping of sites. Has a parent which is another site group.
  • Site: Site in the CMS. Has a parent which is a site group.

(G) -> Site Group (S) -> Site

SiteHierarchy.svg
Here we can see a simple example of a site hierarchy.

(S) Life Sciences and (S) Biology are both sites. They are part of the (G) Life Sciences Sites group, which is part of the (G) BYU Sites group, which is part of the (G) All Sites group.

Similarly on the other side, (S) BYUH Home is a site. It is part of the (G) Hawaii Sites group, which is of course part of the (G) All Sites group.

Every site or site group can have at most ONE parent. A site or site group with NO parents implicitly has a parent of (G) All Sites.

How are these used? We can use these to manage users and assign permissions over multiple sites very easily.

For example, if you are an admin of the (G) Life Sciences Sites group, you are an admin of ALL sites below it.

You can apply permissions on a site by site basis or for any specific site group. This can be used to manage users by following the rule:

If you are a manager, you manage ALL users at your site hierarchy level and below.

For example, if you are an admin of the (G) Life Sciences Sites group, you can only manage users who are also associated with the group, or users associated with sites below ((S) Life Sciences or (S) Biology). You would NOT be able to modify or access users associated with (S) BYUH Home.

The user manager experience and permission assignment will be covered in more detail shortly.

Publishing

You can set the hierarchy group for a specific at Sites & Settings -> Hierarchy Group

hierarchyGroup.png

To publish a site group, you can go to Permissions & Roles -> New Site Grouping

permissionsAndRoles.png
siteGrouping.png

Here, you can set the name (must be unique), and the direct parent. From our previous example, if you are publishing (G) Life Sciences Sites, you would set the parent to (G) BYU Sites.

To note: this area (Permissions & Roles) is likely restricted to those with admin permissions.

Permissions/Roles

To assign permissions to a user, you must go to the Users area. This area is likely restricted to those with site admin permissions.

usersArea.png

In this area, you can modify and create new users that YOU manage. To assign permissions, go to the Permissions tab of a user.

In here, you will find a field called Permission Sets.

A Permission Set is a set of permissions that define what the user can do at some site hierarchy level.

Let's look at the layout of a permission set.

permissionSet.png

There are two ways to assign permissions to a user as shown within the permission set: Permissions or Roles.

Some definitions:

  • Permission: An individual permission specifying one thing a user can do.
  • Role: A business grouping of Permissions. Roles are nice because you can group together common permissions that are typically used together.

A permission set can have any number of permissions and/or roles.

Let's go over the fields in this permisison set.

  • Title: An identifying value of this permission set. Will default to the Site Hierarchy value.
  • Site Hierarchy: REQUIRED. Defines which site hierarchy (site group or site) that these permissions will apply
  • Roles: READ ONLY. A display for the current roles on this permission set
  • Role Publisher: A publisher to add roles to this permission set
  • Permissions: READ ONLY. A display for the current permissions on this permission set
  • Permission Publisher: A publisher to add permissions to this permission set
  • Encompassing Section Restrictions: Limit the permissions in this permission set to a specific set of sections.

Publishing

Site Hierarchy

Select the search popout and choose Site or Site Grouping. These are filtered based on what YOU have access to. Here you can select which site hierarchy level you would like to apply these permissions/roles.

siteHierarchyOnPermissionSet.png
In this example, I have selected the Life Sciences Sites site group.

Roles

To add/remove a role to a permission set, select the Role Publisher field and select Add or Remove, based on what you want to do.

addOrRemove.png

If we select Add, we can see a dropdown where we select roles to apply to this permission set.

IMPORTANT: These roles are filtered based on what you have access to on the selected site hierarchy!

rolePublisher.png

After clicking Save, the Role Publisher will be set to None and the selected roles will be added to the Roles field.

Roles must be manually published (that will be detailed in the next section).

Permissions

Similar to roles, we can select Add or Remove. There is one extra field in the permission publisher, which is the Filtered Type. This field only acts as a filter for the Permissions field below. IMPORTANT: These permissions are filtered based on what you have access to on the selected site hierarchy!

permissionPublisher.png

Most of these permissions are automatically generated and don't need to be manually published, except for Type Permissions. Publishing these will be detailed in the next section.

After clicking Save, the Permission Publisher will be set to None and the selected permissions will be added to the Permissions field.

Publishing Permissions/Roles

Since roles and type permissions cannot be automatically generated, they must be manually published instead. These can be published in the Permissions & Roles section that we saw earlier.

Other than the Site Grouping section, there are two other sections: Type and Permission Role

Type Permissions

These need to be manually published since there are custom fields that need to be defined.

typePermission.png

These fields are the same as the default Brightspot users and roles system.

What makes type permissions more interesting than other permissions (UI, Area, Developer), is that there are some extra fields we can filter on (i.e. the actions field).

For example: If you have Article -> Read only, then you will NOT be able to assign or see permissions such as Article -> Write or Article -> All actions.

Permission Roles

If you create a new Permission Role, you can see there are only a couple of fields.

permissionRole.png

The fields include:

  • Name: REQUIRED. Name to identify the role
  • Permissions: READ ONLY. A display for the current permissions on this permission set
  • Permission Publisher: A publisher to add permissions to this permission set

The permission publishing system is almost exactly the same as in a permission set.

There is one key difference though: There is no site hierarchy to filter the permissions on! The way the permissions are filtered in the permission dropdown is by the site that you are currently on. You will only be able to see permissions for which you have access on the site you are currently on.

If there are permissions that you need to assign that you don't have access to on the current site, you need to change sites to whatever site will give you the correct access.

User Management

The final main aspect of the new permissioning system is the ability to manage users. We will (again) utilize the site hierarchy system to determine which users you can manage and which ones you can't.

In the Users admin area, you can see which users you manage.

managedUsers.png

These are only going to be users that are at your management site hierarchy level or lower. You are defined as a "User manager" if you have access to the Users admin area.

For example (refer to our previous site hierarchy diagram):

  • If you are a (S) Life Sciences manager, you will be able to see all users (including other managers) who have a permission set with the site hierarchy of (S) Life Sciences.
  • If you are also a (S) Biology editor, you will NOT be able to see users who have a permission set with a site hierarchy of (S) Biology.

User Adoption

You may need to give permissions to someone who already has Brightspot rights, but not for your site or site group.

For example, an admin of the site (S) Life Sciences, can see users who have access to that site.

Another user, John, has rights to (S) Biology. The (S) Life Sciences site admin would like to give him rights to that site, but cannot see John's user account to give permissions.

There are two possible solutions to this problem:

  1. Reach out to a manager of the site group (G) Life Sciences Sites that contains both (S) Life Sciences and (S) Biology to give John the permissions needed, or
  2. Adopt John into the (S) Life Sciences site hierarchy.

You can see the Adopt User area under the admin section.

adoptUserArea.png

Clicking this opens up an Adoption Form. This form allows you to select a user and apply a permission set to them.

Fields:

  • User: User to apply the permission set to
  • PermissionSet: Standard permission set to apply to the user. All standard
adoptionForm.png

After selecting John as the user, you can give him a permission set. This will apply the permission set to Johns user, and then you will be able to manage his user and give him the permissions he needs.

SAML Provisions (Net ID and GRO groups)

Permissions and roles can be provisioned based on a user's net ID, or a GRO group (referred to in Brightspot as a SAML group).

Previously, these attributes were assigned on the Tool Role and the role was applied on login. Now, you can provision permission sets on users via the SAML Permission Provision area. This area will likely only be available to admin users.

A SAML Provision is a piece of content that defines a permission set to apply to users based on one or more Net IDs, one or more SAML group (GRO group), or both.

Looking at an example, after selecting NEW SAML PROVISION, we can see this form.

samlProvisionForm.png

Fields:

  • Net Ids: One or more net IDs to apply this permission set to
  • Saml Groups: One or more SAML groups to apply this permission set to
  • Permission Set: Standard permission set form. It will be filtered as other permission set forms are.

This permission set will be applied to any user who matches ANY of the net IDs or SAML groups. If they already have a permission set with the selected site hierarchy, the new permission set (from the SAML provision) and the existing permission set will be merged together.

The permissions and roles applied via a SAML provision will be tracked and constantly updated whenever the user logs in. If a SAML Provision was applied to a user, and that SAML provision was deleted/modified at some point, this WILL be reflected on the user the next time they log in.

Filtering

You can also filter SAML provisions in the SAML Permission Provisions area. Type in the desired Net ID/SAML group in the filter fields and it should filter the existing provisions by the provided values.

Related Training

data-content-type="oneOffPage"

How to get a list of users who have access to a site

Add and remove users' access to edit or administer Brightspot websites.
overrideBackgroundColorOrImage= overrideTextColor= overrideTextAlignment= overrideCardHideSection= overrideCardHideByline= overrideCardHideDescription= overridebuttonBgColor= overrideButtonText= overrideTextAlignment=
data-content-type="oneOffPage"

How to Remove User Permissions

Add and remove users' access to edit or administer Brightspot websites.
overrideBackgroundColorOrImage= overrideTextColor= overrideTextAlignment= overrideCardHideSection= overrideCardHideByline= overrideCardHideDescription= overridebuttonBgColor= overrideButtonText= overrideTextAlignment=
data-content-type="oneOffPage"

How to Assign User Permissions

Add and remove users' access to edit or administer Brightspot websites.
overrideBackgroundColorOrImage= overrideTextColor= overrideTextAlignment= overrideCardHideSection= overrideCardHideByline= overrideCardHideDescription= overridebuttonBgColor= overrideButtonText= overrideTextAlignment=
overrideBackgroundColorOrImage= overrideTextColor= overrideTextAlignment= overrideCardHideSection= overrideCardHideByline= overrideCardHideDescription= overridebuttonBgColor= overrideButtonText=