Notifying Recipients of Changes to Task Status

Designing Human Tasks 27-67 A shared notification email is generated once for a user locale in a group or application role, thereby saving time in notification email content generation. The email is sent to all users in the group or application role.

27.3.10.10 Customizing Notification Headers

Custom notification headers are used to specify name and value pairs to identify key fields within the notification. These entries can be used by users to define delivery preferences for their notifications. For example: You can set Name to ApprovalType and value to Expense or Name to Priority and value to High. Users can then specify delivery preferences in Oracle BPM Worklist. These preferences can be based on the contents of the notification. Note that the rule-based notification service is only used to identify the preferred notification channel to use. The address for the preferred channel is still obtained from the identity service. To customize notification headers: 1. In the Notification section, click the Advanced tab. 2. Expand Notification Header Attributes. 3. Add name and pair value parameters by name or XPath expression. For more information about preferences, see the following sections: ■ Section 31.2.8, How to Send Inbound and Outbound Attachments ■ Section 31.2.14, How to Create Custom Notification Headers ■ Part XI, Using Oracle User Messaging Service

27.3.11 How to Specify Access Policies and Task Actions on Task Content

You can specify access rules on task content and actions to perform on that content.

27.3.11.1 Specifying Access Policies on Task Content

You can specify access rules that determine the parts of a task that participants can view and update. Access rules are enforced by the workflow service by applying rules on the task object during the retrieval and update of the task. Notes: ■ Since all or a subset of users receive the same email, the users in the group or application role are expected to have the same privilege. This ensures that the user does not see task details to which they are not entitled. ■ When sending one email to all users, the maximum number of characters allowed in the address field is 2000. If the limit is exceeded, email is sent to only those user addresses contained within the maximum limit. Note: Task content access rules and task actions access rules exist independently of one another. 27-68 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite

27.3.11.1.1 Introduction to Access Rules Access rules are computed based on the

following details: ■ Any attribute configured with access rules declines any permissions for roles not configured against it. For example, assume you configure the payload to be read by assignees. This action enables only assignees and nobody else to have read permissions. No one, including assignees, has write permissions. ■ Any attribute not configured with access rules has all permissions. ■ If any payload message attribute is configured with access rules, any configurations for the payload itself are ignored due to potential conflicts. In this case, the returned map by the API does not contain any entry for the payload. Write permissions automatically provide read permissions. ■ If only a subset of message attributes is configured with access rules, all message attributes not involved have all permissions. ■ Only comments and attachments have add permissions. ■ Write permissions on certain attributes are meaningless. For example, write permissions on history do not grant or decline any privileges on history. ■ The following date attributes are configured as one in the Human Task Editor. The map returned by TaskMetadataService.getVisibilityRules contains one key for each. Similarly, if the participant does not have read permissions on DATES, the task does not contain any of the following task attributes: – START_DATE – END_DATE – ASSIGNED_DATE – SYSTEM_END_DATE – CREATED_DATE – EXPIRATION_DATE – ALL_UPDATED_DATE ■ The following assignee attributes are configured as one in the Human Task Editor. The map returned by TaskMetadataService.getVisibilityRules contains one key for each of the following. Similarly, if the participant does not have read permissions on ASSIGNEES, the task does not contain any of the following task attributes: – ASSIGNEES – ASSIGNEE_USERS – ASSIGNEE_GROUPS – ACQUIRED_BY ■ Mapped attributes do not have individual representation in the map returned by TaskMetadataService.getVisibilityRules. ■ All message attributes in the map returned by TaskMetadataService.getVisibilityRules are prefixed by ITaskMetadataService.TASK_VISIBILITY_ATTRIBUTE_PAYLOAD_ MESSAGE_ATTR_PREFIX PAYLOAD. An application can also create pages to display or not display task attributes based on the access rules. This can be achieved by retrieving a participant’s access rules by Designing Human Tasks 27-69 calling the API on oracle.bpel.services.workflow.metadata.ITaskMetadataService. Example 27–1 provides details. Example 27–1 API Call public MapString, IPrivilege getTaskVisibilityRulesIWorkflowContext context, String taskId throws TaskMetadataServiceException; For more information about this method, see Oracle Fusion Middleware Workflow Services Java API Reference for Oracle SOA Suite.

27.3.11.1.2 Specifying User Privileges for Acting on Task Content You can specify the

privileges that specific users such as the task creator or owner have for acting on specific task content such as a payload. To specify user privileges for acting on task content: 1. Click the Access tab. 2. Click the Content tab. 3. Select the task content for which to specify access privileges, as shown in Figure 27–64 . Figure 27–64 Configure Task Content Access

4. Assign privileges read, write, or no access to users to act upon task content. Note

that a user cannot be assigned a privilege above their highest level. For example, an ADMIN user cannot be assigned write access on the PAYLOAD task content. Table 27–17 shows the maximum privilege each user has on task content. Table 27–17 Highest Privilege Levels for Users of Task Content Task Content Individual with Read Access Individual with Write Access Assignees Admin, Approvers, Assignees, Creator, Owner, Reviewers -- Attachments Admin, Approvers Assignees, Creator, Owner, Reviewers