Default permission

An admin user can grant default permissions for a User or a Role. This defines default permission for other users or roles on XDM objects such as tasks or environments created by the specified grantor. The grantee will receive the default permissions whenever the grantor creates an object of corresponding to one of the specified types. With the apply action the default permissions are granted on all existing objects for which the grantor is the owner.

The difference to user default permissions is that in this case the specified grantor can be a Role. The effect in this case is as if each member of the given role were to specify the same user default permissions.

It is not possible to define a default permission specifying the same user as grantor and grantee, because a user is always owner of all objects he/she creates. However, it is possible to define a default permission specifying the same role as grantor and grantee.

Concepts and more information

Permissions

Default Permissions have specific permissions to manage user access. The table below displays the available permissions and their purposes.

For more details about the concept of XDMs permission management refer to Permission Management.

Permission

Description

ADMINISTRATION

Specifies that the grantee can grant and revoke permissions to and from other users.

A user that creates an object automatically receives the ADMINISTRATION permission on that object.

DELETE

Specifies that the grantee can delete objects of the selected types.

READ

Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all of the object’s details, such as rules or access permissions.

In addition, the grantee can reference this object. For example, a user who has READ permission on a credential object can refer to this credential object when creating a new database connection.

WRITE

Specifies that the grantee has the permission to change the settings and attributes of an object. This also includes modifying any rule lists that might be associated with the object (for example, the selection rules of a task template).

Properties

The table below documents the available properties for default permissions. The 'name' column displays the property name as it can be used in Groovy and Java Scripts.

Name

Type

Default

Description

Administration permission

administration

Boolean

false

Specifies that the grantee can grant and revoke permissions to and from other users.

A user that creates an object automatically receives the ADMINISTRATION permission on that object.

Apply SQL

applySql

Boolean

false

Specifies that the grantee can apply DDL/DML statements against the database connection.

Browse permission

browse

Boolean

false

Specifies that the grantee is allowed to see the contents of database tables when using the schema browser, and when inspecting the output of an XDM task that provides a data preview. This permission only applies to connections.

Delete

delete

Boolean

false

Specifies that the grantee can delete objects of the selected types.

Diagnose permission

diagnose

Boolean

false

This permission controls access to diagnostic data of a task execution. The diagnostic data consists of the stages, their outputs and the batch reports.

Execute

execute

Boolean

false

Specifies that the grantee may execute the object, or schedule the object for later execution. This permission only applies to objects that are executable, i.e. tasks, task templates, workflows, workflow templates, and data shops.

Grantee

grantee

PermissionRecipient

n/a

The user or role to whom the specified permissions are granted by default.

Grantor

grantor

PermissionRecipient

n/a

The user or role who grants the specified permissions by default.

Modify data

modifyData

Boolean

false

Specifies that the grantee can write table rows which are protected by a data reservation and update the properties of the data reservation.

Read permission

read

Boolean

true

Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all of the object’s details, such as rules or access permissions.

In addition, the grantee can reference this object. For example, a user who has READ permission on a credential object can refer to this credential object when creating a new database connection.

Script usage permission

script

Boolean

false

Specifies that the object can be used as a parameter for an XDM task stage hook. This permission only applies to credentials. If a user does not have the SCRIPT privilege for the credential, it is not displayed in the drop-down list where the credential for a task stage hook parameter needs to be selected.

Use as source

sourceUsage

Boolean

false

Specifies that the object can be used as the source for an XDM task. This permission only applies to environments and connections. If a user does not have the SOURCE_USAGE privilege for an environment or connection, it is not displayed in the drop-down list where the source environment or connection for a task needs to be selected.

Use as target

targetUsage

Boolean

false

Specifies that the object can be used as the target for an XDM task. This permission only applies to environments and connections. If a user does not have the TARGET_USAGE privilege for an environment or connection, it is not displayed in the drop-down list where the target environment or connection for a task needs to be selected.

Object type

types

String

n/a

List of XDM object types for which the specified permissions should be granted (task templates, connections, credentials, and so on). Each item in the list has a checkbox with which it can be selected or deselected.

The following types are available:

  • Announcement

  • Application model

  • Classification term

  • Connection

  • Credential

  • Custom parameter definition

  • Data reservation

  • Data request form

  • Environment

  • Execution (also used for scheduled executions)

  • External tool

  • File

  • Matcher

  • Modification method

  • Modification set

  • Storage location

  • Task execution report

  • Task stage hook

  • Task template

  • Workflow template

Write permission

write

Boolean

false

Specifies that the grantee has the permission to change the settings and attributes of an object. This also includes modifying any rule lists that might be associated with the object (for example, the selection rules of a task template).

Actions

The available actions are described below. Some actions apply to the list, while others are specific to selected default permissions.

List Actions

The following actions are available on the default permissions list. If the action is disabled a tooltip will provide the exact reason for the deactivation. The required permissions are described in detail for each action.

  • Bulk Create Permission

  • Bulk Delete

  • Bulk Export

  • Create

  • List History

Create a new permission on the selected objects. Shows in the result list whether the permission could be granted on the respective object. Only these permissions can be granted that are existing on the underlying object.

A permission in the result list can have three different states, these are:

CREATED

The permission successfully granted on the object.

MERGED

The granted permission already exists on the object and merged with the new permission.

SKIPPED

The permission could not be granted, because of missing administration permission on the object.

The following permissions are required on the list:

  • ADMINISTRATION

  • READ

Delete the selected objects.

The following options are available:

Cascade

Recursively delete depending objects.

When using cascade, dependent objects are deleted first also with cascade enabled. Thus, a cascade deletion is a recursive function that deeply searches for dependent objects and deletes them first. There is only a confirmation for the first object. The dependent objects are deleted without confirmation but only when the user has the DELETE permission.

This feature is only available in development mode. More information about development mode can be found in the chapter User Settings. It should be used with caution.

An object in the result list can have two different states, these are:

DELETED

The object could be deleted.

NOT_DELETED

The object could be not deleted. This may be because the executing person does not have a delete permission on the object or the object is still referenced by others. A detailed reason can be determined with the help of the error message. If the object is still in use, these objects are also displayed.

The following permissions are required on the list:

  • DELETE

  • READ

Exports the selected objects.

YAML

Generates a YAML file containing all the object’s settings. The user has the option to download the export file, or to paste the content in the import dialog. The YAML export is particularly suitable for importing the exported objects again via the XDM UI.

ZIP

This export writes several individual YAML-files. Each YAML-file is stored in a directory according to its type. For example, when exporting a native table backup task template named 'A backup template', a YAML-file 'A backup template.yaml' is created inside the directory /TaskTemplate/native-table-backup-task-template/ of the ZIP-file. This kind of export is suitable for usage in git-repositories together with XDM’s configuration as code feature.

Related and dependent objects can optionally be included in the export. The export dialog has the following options:

Include dependent objects

Dependent objects only belong to the exported object like rules and tasks.

Include permissions

Permissions of each exported object, only when the object supports permissions. Some objects like rules don’t have permissions.

Include referenced objects

Referenced objects exist by their own and are used in the exported object like connections and environments.

Include objects that depend on referenced objects

Also include the dependent objects of the referenced objects. E.g. the rules of a modification set or the rules in an application model version.

Objects on which the user does not have READ permission are not exported. This includes dependent and referenced objects. However, the reference to an object will be exported. For example a connection object would refer to the credential, even if the user does not have READ permission on the credential. The definition of the credential object itself will not be part of the export file. This can lead to issues during the import, because the connection cannot be created without an existing credential.

The following permissions are required on the list:

  • READ

Creates a new object in the current list. Depending on the object type either a popup dialog is shown for the most important settings, or the complete object is shown in edit mode. The dialog provides the option to create the object and remain in the current list or to switch to the newly created object in edit mode to perform further changes.

The following permissions are required on the list:

  • CREATE

The history list tracks all modifications made to objects within it. A new record is added each time an object is created, edited, or deleted. A record indicates who made the change, which object was affected, and when the change was made.

For more information about the concept of the history refer to the history concepts.

The following permissions are required on the list:

  • READ

Object Actions

The following actions are available on specific default permissions. In order to execute the action, the user must possess the necessary permissions for the object. The permissions required for each action are described individually. If the user does not have these permissions, the action will be disabled and the tooltip will provide the exact reason for the deactivation.

  • Apply

  • Delete

  • Edit

  • Export

  • Object History

  • Permission Check

This action applies the specified privileges to all existing matching objects. Matching objects are those of the specified object type, which were created by the specified grantor. The grantor is identified by the grantor type and a grantor name. In the case of user default permissions, the grantor type is User and the grantor is the current user by default.

If the apply action is performed on default permissions with the grantor type Role, all objects created by members of the selected role are collected and the default permission is applied to all these objects.

The apply action for default permissions for the grantor type Role is applied to the users who had these roles at the last login time. This means that if roles are changed for a user who has not logged in in the meantime, the applying is used for the roles stored up to this point in time.

The apply action can only be used in either of the following modes:

REPLACE

In this mode, the apply action replaces all privileges on existing matching objects with the privileges specified by the default/user permission on which the apply action is invoked. Any additional privileges that existed on the matching objects will be revoked for the given grantee.

MERGE

In this mode, the apply action merges the existing privileges on the matching objects with those specified by the default/user permission on which the apply action is invoked. Any additional privileges that existed on the matching objects will be retained.

In both REPLACE and MERGE mode, only those permissions derived from the existing user/default permission will be updated. Permissions for other grantees are not affected.

The following permissions are required:

  • READ

Delete the object. If the object is still used by another entity, an error message is displayed, and the object is not deleted. The delete operation must be confirmed in a separate popup.

The following options are available:

Cascade

Recursively delete depending objects.

When using cascade, dependent objects are deleted first also with cascade enabled. Thus, a cascade deletion is a recursive function that deeply searches for dependent objects and deletes them first. There is only a confirmation for the first object. The dependent objects are deleted without confirmation but only when the user has the DELETE permission.

This feature is only available in development mode. More information about development mode can be found in the chapter User Settings. It should be used with caution.

The following permissions are required:

  • DELETE

  • READ

Opens the current entity in edit mode.

The following permissions are required:

  • READ

  • WRITE

This action allows to export XDM objects in different formats in order to import them via export or CasC in another environment.

Refer to configuration of export for more information.

Related and dependent objects can optionally be included in the export. The export dialog has the following options:

Include dependent objects

Dependent objects only belong to the exported object like rules and tasks.

Include permissions

Permissions of each exported object, only when the object supports permissions. Some objects like rules don’t have permissions.

Include referenced objects

Referenced objects exist by their own and are used in the exported object like connections and environments.

Include objects that depend on referenced objects

Also include the dependent objects of the referenced objects. E.g. the rules of a modification set or the rules in an application model version.

Include implicit created objects

Implicit created objects are tasks or workflows which were automatically created for execution. These objects won’t be exported by default, but can be included by setting this flag. When exporting implicit objects, make sure that the Include dependent objects flag is also enabled.

Objects on which the user does not have READ permission are not exported. This includes dependent and referenced objects. However, the reference to an object will be exported.

For example a connection object would refer to the credential, even if the user does not have READ permission on the credential. The definition of the credential object itself will not be part of the export file. This can lead to issues during the import, because the connection cannot be created without an existing credential.

The following permissions are required:

  • READ

The history displays all changes made to the respective XDM object, including any changes made to its rules.

Each change record includes information about the operation performed (e.g. CREATE, UPDATE, DELETE), the timestamp, and the user responsible for the change.

For more information about the concept of the history refer to the history concepts.

The following permissions are required:

  • READ

The check verifies that the current user has the authorization to access the object. The check can also be performed for a specific user or role, if needed. By default, the check is performed using the current user’s credentials. It is then applied to child and referenced objects.

Additional permission checks are applied when these can be inferred from the context in which the check was started. For example, if the check is performed on a table copy task, the referenced source and target connections are checked to determine whether the given identity has source or target usage permission respectively.

The following permissions are required:

  • READ