User default permission

Users can grant default permissions for other users or roles on their own XDM objects such as tasks and environments. The grantee will receive the default permissions whenever the user creates an object of the corresponding type. With the apply action the default permissions are granted on all existing objects for which the user is the owner.

A user can not define default permissions for him/herself, because the user is always owner of all objects he/she creates. It is, however, possible to grant default permissions on a role of which the user is a member.

Concepts and more information

Properties

The table below documents the available properties for user 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.

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 user default permissions.

List Actions

The following actions are available on the user 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 Delete

  • Create

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

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

Object Actions

The following actions are available on specific user 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

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