Understanding Access Rights

Users require specific access rights to perform operations, for example, "User Alice needs MODIFY access right on scenario S1 to modify the content of a row". For more details, please refer to Chapter Managing the Application Data.

At least one access right requirement is emitted by basically any operation. It is composed of:

  • a user,

  • an access right,

  • and an application element.

An access right requirement is decided by evaluating it against the permission rules. This is a three-step process:

  1. Applicable rules are looked up;

  2. The most specific ones are retained;

  3. The decision is computed.

Access rights can be of the following types: ACCESS, MODIFY, DELETE, CREATE, or PERMISSIONS.

Operations can be performed on the following application elements:

  • Workspaces, scenarios and scenario links. Note that:

    • This includes the creation, access and deletion as well as the edition of their properties and content.

    • A scenario contains an instance of the data model defined before generating the application. For more details, please refer to Chapter Defining the Data Model.

    • A workspace contains a number of scenarios. A scenario is always contained in a workspace.

    • Scenarios and workspaces have an owner, who initially is the user that created them.

    • A scenario can be locked.

    • If the application uses a composite data model:

      • In order to have ACCESS permission on a scenario, the user must have ACCESS permission on all visible scenarios.

      • To edit an entity attribute (in scenario S1 for example) that is retrieved from a referenced scenario (S2), the user must have MODIFY permission on said referenced scenario (S2).

    • Scenario links can be created from the Scenario list widget using the option Create link.

      • Creating a scenario link to a scenario adds said scenario to a workspace accessible to users that cannot access the current Workspace.

      • Editing a scenario in a workspace also impacts its corresponding scenario links, even when they are in other workspaces.

      • Deleting a scenario link does not delete the linked scenario. However, deleting a scenario does delete all related links.

      • In a composite data model application, when adding a scenario that references other scenarios, it is possible to select a scenario link or a normal scenario. Once the scenario is added, a permission rule is also created to make the referenced scenario accessible to everyone. This is required, in case it is moved into another workspace for instance, to prevent losing ACCESS to the new scenario which, itself, also requires ACCESS to the referenced scenario. For more details, please refer to Section Understanding Operations.

  • Views, dashboards and application preferences. Note that:

    • This includes the creation of a view or dashboard, access to the view or dashboard, modification of a property of the view or dashboard (e.g. its name) or of its content (the widgets it contains), deletion of the view or dashboard.

    • Although views and dashboard are different from a user experience viewpoint, they are gathered as a single application element type.

    • A view or dashboard is not contained in another application element. It has an owner, who initially is the user that created it.

  • Tasks and jobs. Note that:

    • There is no operation on a task except including it in the list of tasks, as they are created statically by code. On the other hand, jobs can be created, their properties (step list, outputs, log) can be displayed, a job can be stopped, and it can be erased from the list of jobs.

    • As a job is the execution of a task, jobs that execute a given task are considered to be contained by the task, in the same ways as a workspace contains scenarios. From the viewpoint of the permission system, launching a task execution is thus like creating a job contained in the task.

    • Jobs have an owner, who is the user that launched their execution. Tasks have no owner.

  • Permissions. Note that:

    • Like scenarios, workspaces, tasks, jobs, views and dashboards, permission rules can also be configured through application preferences and permissions management to set who is allowed to access and modify them. For more details, please refer to Section Setting Application Preferences.

    • Permission rules cannot be deleted nor created (one global instance of each rule preexists). They have no owner. For more details, please refer to Section Understanding Permission Rules and Rulesets.

The permission system evaluates each access required by the operation and the operation is allowed or forbidden. The table below lists the classical Create, Read, Update and Delete operations on each of the application element types, and indicates which accesses they require.

CRUD Operations on Common Element Types