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 calling the API on oracle.bpel.services.workflow.metadata.ITaskMetadataService. as shown in the example below:

public Map<String, IPrivilege> getTaskVisibilityRules(IWorkflowContext context,
                                      String taskId)
   throws TaskMetadataServiceException;

For more information about this method, see Workflow Services Java API Reference for Oracle SOA Suite.