Permissions

The third step to implement the organization's governance model in Anjana Data, after defining organizational units and roles, is to establish the permissions configuration.

Permissions are what enable each role to perform low-level actions on the platform. They constitute the link between the defined role and the effective actions that users can execute on the different objects and modules of Anjana Data.

Through them, it is possible to granularize operational control and ensure that the responsibilities associated with each role are materialized in accordance with the organization's governance model.

Concept of Permissions in Anjana Data

Each permission specifies what a role can do on an object or set of objects on the platform. Permissions can be applied in two ways:

• Specific permissions by entity or relationship type:
  Applied based on the metamodel (e.g. Dataset, Business Terms, Reports, AI Models…) and determine which operations can be performed on each object type (Creation and modification, status change, deprecation, organizational unit change and organizational unit owner).

• Global application-level permissions:
  Applied transversally across the platform, regardless of domain or entity (e.g. ACCESS, ADMIN, LINEAGE_ACCESS).

Permission Types

1. Permissions by entities and relationships (metamodel)

• AUTOMATIC_METADATA: creation of entities or relationships in an assisted manner in the creation wizard of the data portal through automatic discovery and import via plugin.

• CHANGE_STATUS: activate or deactivate non-native entities or relationships.

• CHANGE_OU: modify the organizational unit of an entity to transfer custody of the asset.

• CREATION_MODIF: create, modify and submit entities or relationships for validation.

• DELETE_ALL: delete entities or relationships, regardless of the creator.

• DELETE_MY_OBJ: delete entities or relationships created by the user themselves.

• DEPRECATION: manually deprecate native entities.

• ORGANIZATIONAL_UNIT_OWNER: act as owner of entities within the assigned Organizational Unit (OU).

  • Users with this permission will appear on the Stakeholders screen as Owner.

  • When creating and approving a DSA, these users may be automatically added to the corresponding access group (this automation depends on the technical configuration of the plugin that manages adherences).

2. Global platform-level permissions

• ACCESS: access to the data portal for object viewing (for subtype ALL) and adherence cart (for subtype ADHERENCE).

• ADMIN: access to the administration panel.

• API_ADMIN: use of the administrative API, bulk editing of objects in the data portal, and use of administration panel actions (Actions).

• CREDENTIAL_ADMIN: credential management for authentication (via database) and authorization (access to Users and User-OU-Roles tables) and access to technical configuration (the appConfigurations table in the configuration panel).

• LINEAGE_ACCESS: visualization of lineage in the data portal.

• WIZARD: access to the object creation wizard (requires CREATION_MODIF or AUTOMATIC_METADATA) in the data portal.

• WORKFLOW_ACCESS: access, approval or rejection of validation workflows in the data portal.

• API_DOC: access to API documentation visualization through the application.

Permissions Table in the Configuration Panel (Administrator View)

Permissions are configured in the Permissions table of the configuration panel. Defining permissions is an indispensable step to access the platform (data portal or configuration panel) and perform actions within it.

Structure of the Permissions Table

Each registered permission is characterized by the following fields:

Each record in the table defines a permission and is composed of the following fields:

• id: unique identifier of the permission within the table.

  • Automatically assigned based on database sequences.

• action: specific action that is authorized.

  • To assign actions, see the possible combinations in the permissions table.

• subType: object or entity from the metamodel to which the permitted action applies.

  • To assign actions, see the possible combinations in the permissions table.

• role: reference to the role to which the permission is assigned.

  • The selection dropdown shows the roles configured in Roles. If the expected role does not appear, review the Roles configuration.

action and subType combinations:

(1): Name from the object_subtype table.

(2): Permissions must not be defined for DATASET_FIELD since, for it, the permissions of DATASET apply.

(3): CHANGE_OU cannot be used for INSTANCE.

Adding a Permission to the Permissions Table

Adding a new permission for a role (for example, deleting data treatments created by any user) involves adding a new record to the Permissions table.

To add the record and register a new permission:

1. Click the New button in the upper right corner. This will open a wizard with the fields defined in the Table Structure section of Permissions.

2. Fill in the permission fields according to the structure described in the previous section.

3. Click Save to save the role or Cancel to discard.

Modifying a Permission in the Permissions Table

Modifying the action, subType or role fields must be done with caution, as it can have an impact on:

• The capabilities of users within the platform.

• Workflow validation, since if the validating user does not have access to the module, they will not be able to perform the validation step.

Configuring Permissions via Direct Database Access (Developer View)

The database (DB) table containing the permissions parameters has the following structure:

Below is an example query to configure the permissions associated with the DPO role:

INSERT INTO zeus."permission"
(id_permission, permission_action, sub_type, id_role)
VALUES
(258, 'ACCESS', 'ALL', 16),
(259, 'CREATION_MODIF', 'TRATAMIENTO_DE_DATOS', 16),
(260, 'DELETE_ALL', 'TRATAMIENTO_DE_DATOS', 16),
(261, 'WORKFLOW_ACCESS', 'ALL', 16),
(262, 'LINEAGE_ACCESS', 'ALL', 16);