Understanding Permission Inheritance

Overview

Permissions can be assigned one of two ways: explicitly or by inheritance.

• Explicit permissions are permissions that are set by default when an item is created, or by user action.

• Inherited permissions are permissions that are given to an item because it is a child of a parent item (such as a folder, workbook, or datasource).

Inherited permissions function similarly to the way rights are typically managed for groups of users. Items within the parent (folder, workbook, or datasource) inherit all the access permissions of the parent.

For example, you might explicitly give read permissions to a user named Jonathan Pollard for a folder named Folder 1.

All subfolders, topics, workbooks, and projects created within Folder 1 automatically inherit the permissions assigned to Folder 1. Note that inherited permissions are denoted by a gray-colored checkbox in the modal below (and you will not be able to remove permissions without disabling permission inheritance).

Permission Inheritance Precedence

1. Inherit from the containing Folder for Analyses, Projects, Topics, and Sub-Folders (or the containing Asset for Assets, Signals, Scalars, and Conditions within an asset tree).

2. If the item comes from a datasource outside of Seeq, inherit the permissions from that datasource.

3. If an item is scoped to an analysis, inherit the permissions from that analysis.

Users receive the highest level of permissions possible (explicitly or via inheritance) if they receive access through multiple means.

Formula parameters do not denote permission inheritance, so calculated items do not inherit permissions of the stored items they are derived from.

Examples

Explicit and Inherited Permissions

In this example, let’s say you created a CalculatedCondition called FunTimes within in a new Workbook named HappyDays. You offer your colleague Sarah Johnson read access to the FunTimes condition, and manage access to the HappyDays workbook.

Sarah Johnson now has manage access to both the HappyDays workbook and the FunTimes condition. This is because the FunTime condition offers two levels of access to Sarah:

• Explicit read permissions to the condition

• Inherited manage permissions from the workbook

Because users receive the highest level of permissions possible, Sarah receives manage access to FunTime and HappyDays. This will be reflected in the Access Control Modal of FunTime via grayed-out checkboxes:

Items Pushed by DataLab

In this example, let’s say you have compiled the data needed in a Data Lab Project to create a StoredSignal in Seeq named CoolTrend. You are ready to push your signal via the spy.push() method. There are two optional arguments, workbook and datasource that will affect the permissions and scope of your new signal. Note that the SPy default (providing no arguments for either workbook or datasource) is functionally equivalent to the first option (setting workbook equal to Data Lab Analysis - From Data Lab, and datasource equal to None).

• workbook="MyWorkbook", datasource=None: Your signal will be locally scoped to MyWorkbook and your data will be stored in the shared Seeq Data Lab datasource. By default, everyone has manage access to both the Seeq Data Lab datasource and all items that are created within. This means that all users who have access to the workbook MyWorkbook will be able to search for, read, and write CoolTrend within that workbook or associated Topics and DataLab Projects. Users who do not have access to the workbook will not be able to find or access CoolTrend in Workbench or Organizer; however, they may still access the signal through the REST API.

• workbook=None, datasource=None: Your signal CoolTrend is globally scoped (available to search for, use, and modify across all of Seeq), and stored in the shared Seeq Data Lab datasource. By default, everyone has manage access to both the Seeq Data Lab datasource and all items that are created within. This means that all users can find and use CoolTrend with manage access.

• workbook=None, datasource="MyDatasource": Your signal CoolTrend is globally scoped (available to search for, use, and modify across all of Seeq), and stored in the datasource MyDatasource. If MyDatasource already exists, CoolTrend will inherit the permissions associated with MyDatasource. If MyDatasource does not exist, a new datasource is created that offers everyone manage access to it and all items that are created in this datasource. This means that all users can find and use CoolTrend with manage access.

• workbook="MyWorkbook", datasource="MyDatasource": Your signal will be locally scoped to MyWorkbook and your data will be stored in the datasource MyDatasource. If MyDatasource already exists, CoolTrend will inherit the permissions associated with MyDatasource. If MyDatasource does not exist, a new datasource is created that offers everyone manage access to it and all items that are created in this datasource. This means that all users who have access to the workbook MyWorkbook will be able to search for, read, and write CoolTrend within that workbook or associated Topics and DataLab Projects. Users who do not have access to the workbook will not be able to find or access CoolTrend in Workbench or Organizer; however, they may still access the signal through the REST API.

Creating a CalculatedItem from a StoredItem

In this example, let’s say you start with a StoredSignal called Temperature from a remote datasource that is configured to permit manage access to only members of the group AwesomeTeam. You are on AwesomeTeam, and you create a CalculatedSignal called AverageTemperature based on your original Temperature signal.

Your new signal, AverageTemperature, inherits permissions from the Seeq Calculations Datasource, not the remote datasource that the Temperature signal is hosted within. This means that AverageTemperature will offer everyone read and write access to the calculation by default. (If an administrator has changed the default permissions or inheritance for the Seeq Calculations Datasource, then AverageTemperature will inherit the permissions of the new configuration).

So who can access AverageTemperature? It depends on how AverageTemperature is scoped.

• If the signal is scoped locally to the workbook (which is both the default and recommended option), then all users who have access to the workbook will be able to search for, read, and write AverageTemperature within that workbook or associated Topics and DataLab Projects. Users who do not have access to the workbook will not be able to find or access AverageTemperature in Workbench or Organizer; however, they may still access the signal through the REST API.

• If the signal is scoped globally, everyone (or the group(s) specified in the overridden permissions for the Seeq Calculations Datasource) will be able to search for, use, and modify AverageTemperature in any workbook, topic, or project.

Items from a CSV File

Items from CSV files are scoped to the workbook they are uploaded from, and as such, inherit the permissions of the workbook they are in.

Content in Corporate Drive

The Corporate Drive is a special folder that the Everyone Group gets read and write access to. Any content that is moved or created in this folder will automatically give everyone read and write access as well.

Disabling Permission Inheritance

If a more advanced permission structure is needed, inheritance may be disabled. Disabling inheritance makes all child permissions modifiable and prevents parent permissions from affecting an item.

Note that on being re-enabled, parent permissions will apply to all children.