Security for Requests

Permissions and Data Access

The following table describes the permissions and data access that are required for request workflow actions.

Table 24-3 Request Actions and Permissions

To perform this request workflow action:	You need this permission:
Assign a request	You must have at least one of these roles or permissions: Current request assignee Owner permission on the view Service Administrator role
Be assigned a request	Participant (Write) access on at least one data chain object in every viewpoint in a request, as follows: For Add, Delete, or Update Properties actions, the user must have Participant (Write) on the node type. For Insert, Move, Reorder, or Remove actions, the user must have Participant (Write) on the hierarchy set.
Be added as a collaborator on a request	Participant (Write) on at least one data chain object in at least one viewpoint in the request. The request actions and property access for request items in a request are determined by the data access permissions on both the request assignee and the collaborator, as follows: For allowed actions, both the assignee and the collaborator must be able to perform the request action in order for that action to be available. For example, in order to insert a node into a hierarchy, both the assignee and collaborator must have Insert as an allowed action on the hierarchy set. If either user does not have the Insert permission, then the option to insert a node is not available. Similarly, a property can be edited only if both the assignee and the collaborator have Edit access to that property.
Make changes to a request using a request load file	The user uploading the request file must have Participant (Write) access (either directly or through permission cascading) to the hierarchy set or node type in order to load a request file. If the load file contains an action or a property update that the user does not have data access to perform (for example, the load file contains a Delete action and the user has data access for Add actions only), the request action is loaded as a request item but it is identified as a validation error when the request is validated. If the load file contains an update for a property that is hidden from the user, that request item is not loaded in the request but it is included in the attached file.
Create a subscription	You must have all of these permissions: Participant (Read) access (either directly or through permission cascading) to the hierarchy set or node type in the source viewpoint. Data Manager permission on the dimension in the target viewpoint Owner permission on the target view
Be eligible to be assigned as a default or alternate assignee of a subscription	Participant (Write) access (either directly or through permission cascading) to the hierarchy set or node type in the target viewpoint. Note: If you are assigning a group, at least one member of the group must have Participant (Write) permission to the hierarchy set or node type in the target viewpoint in order for that group to be available as a selection. If the subscription source request contains an action or a property update that the user does not have data access to perform (for example, the source request contains a Delete action and the user has data access for Add actions only), the request action is loaded as a request item in the target subscription request but it is identified as a validation error when the request is validated. If the subscription source request contains an update for a property that is hidden from the user, that request item is not loaded in the target subscription request but it is included in the attached file.
Approve a request	None, initially. When you add user or group to a policy for a data object, that user or group is granted implicit Participant (Read) permission on that data object. See Configuring Policies
Enrich a request during approval stage	Because enrichers are approvers, they are automatically granted implicit Participant (Read) permission on the data objects in the approval policy. In order to make changes during enrichment, enrichers must also have Participant (Write) on the data chain objects in the request that they want to change. Enrichers can edit request items according to their data access and permissions.

Users

This section describes actions users and Service Administrators can perform on completed and draft requests.

Draft Requests

• Current assignees:
  • Perform request actions according to their permissions and data access
  • Load request items
  • Delete request items
  • Submit the request
  • Download the request items to a file
  • Add, edit, or delete comments and attachments
• Previous participants:
  • View request items, comments, and attachments
  • Add request comments and attachments
  • Inspect the request
  • Validate the request
  • Inspect, validate, and compare viewpoints in the request
  • Download the request items to a file

The creator of a request comment or attachment can edit the comment or attachment while the request is in Draft status.

Completed Requests

Users can see completed requests if they have Participant (Read) access to the view in which the request was made.

Note:

Completed requests cannot be modified, as they provide a historical audit trail.

Service Administrators

Service Administrators can view all requests.

Service Administrators can modify or delete a draft request if they are the current assignee.

Note:

A Service Administrator can be designated as the assignee for a request if they have Participant (Write) permission on the data for which the request was made.

Service Administrators can not modify or submit requests that they are not assigned to, nor can they approve, reject, or push back requests that they are not approvers on.