This view provides the ability to return information about all work items that are currently active in a workflow task. By default, Identity Manager returns information about only a specified work item, not related work items. However, you can use other options to filter work items, and the attributes of the related work items you want to display.
Table 3–74 WorkItem View Form Properties
If you want to ... |
Use this form property |
---|---|
Return all related items by default... |
includeRelatedItems form property |
Request additional attributes to be returned... |
relatedItemAttributes form property |
Limit which items are returned... |
relatedItemFilter form property |
By default, Identity Manager uses the Approval form to display work items. Edit this form by adding the includeRelatedItems element to include related work items:
<Properties> <Property name=’includeRelatedItems’ value=’true’/> </Properties>
You can also request additional attributes with the relatedItemAttributes option. This option can be a CSV string of names or a list of names. You can request the following standard attributes:
request
requester
description
activityName
If you request an attribute name that is not on this list, Identity Manager assumes that it is an arbitrary workflow variable, and the value will be returned if it exists in the work item. Common variables found in the standard workflows include:
accountId
objectType
objectName
diagramLabel
To include the request and description attributes, add these properties to the Approval form:
<Properties> <Property name=’includeRelatedItems’ value=’true’/> <Property name=’relatedItemAttributes’ value=’request,description’/> </Properties>
You can specify the following filter attributes.
Table 3–75 relatedItemFilter Option Values
relatedItemFilter Option Values |
Results of Filtering |
---|---|
itemType |
Only work items with a matching itemType are returned |
activityName |
Only work items created from the same activity are returned |
request |
Only work items with the same user defined request string are returned |
locked |
Only work items that are currently locked for editing are returned |
If more than one filter attribute is on the list, they will be logically AND’ed together. For example, to return only work items with the same request string that are current locked, add this property to the Approval form:
<Properties> <Property name=’includeRelatedItems’ value=’true’/> <Property name=’relatedItemAttributes’value=’request,description’/> <Property name=’relatedItemFilter’ value=’request,locked’/> </Properties> |
An example field that displays a table of information about the related work items was added to the Approval Library form library, the field name is Related Approvers. You can reference this field from the standard Approval form as follows:
<FieldRef name=’Related Approvers’/>
The default time-out interval for locking work items in the repository is five minutes. You can change this value by adding the following element to the RelocatedTypes element of the RepositoryConfiguration Configuration object:
<TypeDataStore typeName=’WorkItem’ lockTimeoutMillis=’10000’/>
The following table lists the top-level WorkItem view attributes.
Table 3–76 WorkItem View Attributes
Attribute |
Editable? |
Data Type |
Required? |
---|---|---|---|
id |
Read |
String | |
name |
Read |
String | |
taskId |
Read |
String | |
taskName |
Read |
String | |
processName |
Read |
String | |
activityName |
Read |
String | |
description |
Read/Write |
String | |
owner |
Read/Write |
String | |
complete |
Read/Write |
Boolean | |
variables | |||
workItem |
Identifies the repository ID of the WorkItem object. Typically generated by Identity Manager and not displayed.
Identifies the repository name of the WorkItem object.
Identifies the repository ID of the workflow TaskInstance. This attribute is used by the system to correlate the work item with the workflow task and must not be changed.
Identifies the repository name of the workflow TaskInstance. This name is typically set to an informative value and can be displayed. Do not modify it. A typical example task name for a user update would be Updating User jdoe.
Identifies the name of the workflow process definition that contains the manual action.
Specifies the name of the workflow activity that contains the manual action.
Contains a textual description of the work item. Its contents are defined by the workflow process definition. The description is typically displayed in tables that summarize the work items for a user, and is often displayed in a work item form.
Identifies the name of the current Identity Manager administrator or user that created the workflow process. This attribute is typically the name of an Identity Manager user. If this work item is assigned to an anonymous user, the name will have the prefix Temp:.
Set to true when the manual action has completed and the workflow is to be resumed. Assignment of the complete attribute must be performed in the Work Item form.
You can edit this Boolean value.
Contains another object whose attributes contain copies of variables from the workflow task. By default, every workflow variable that is in scope when the manual action is activated is copied into the work item. This can be controlled with the Exposed Variables and Editable Variables options in the process definition. Most work item forms display information found under the variables attribute. See the section Using the variables Attribute later in this chapter for more information on using this attribute.
Specifies additional information about the work item. Contains the following attributes:
Contains a list of workflow variables whose values are views. The system uses this attribute to cause view-specific refresh operations when the work item view is refreshed.
Do not change this value.
Contains a list of attributes that describe the specified work item.
Table 3–77 Subattributes of the workItem.related Attribute (Work Item View
Attribute |
Description |
---|---|
name |
Specifies the repository ID of the work item. |
owner |
Identifies the owner of the item. |
locked |
Indicates whether the work item is being edited. A value of true indicates that the work item is currently being edited. |
complete |
Specifies whether the work item has completed. A value of true indicates that the work item completed. |
itemType |
Identifies item type as defined by the process. The default is approval. |
Succinctly describes the purpose of the work item. This description is typically shorter than the value of the description attribute and is often displayed in summary tables.
Identifies the user that initiated the approval.
Indicates whether the time out should be ignored. A value of true (assigned by the system) indicates that this is a read-only work item that may timeout while being viewed. This is a signal to the system that a check-in failure of the Work Item view should be ignored if the work item no longer exists, rather than displaying an error message. This can be useful for work items that are intended only for status messages that time out immediately so the workflow can continue while the user views the messages.
Do not change this value.
When writing a work item form, the most common attributes to reference are complete and variables. The complete attribute must be set to the value true in order for the workflow to be resumed. It is typically set by a hidden field in response to pressing button fields with labels such as Approve and Reject.
The variables attribute contains an object whose values are copies of variables from the workflow task. One of the most common workflow variables used in work items is user, which contains a user view. For example, to reference the global.email attribute from a work item form, use the following path expression:
variables.user.global.email
This differs from attribute paths used in a standard user form. First, the entire view is stored in a workflow variable named user, which results in the user. prefix being required in the attribute path. Next, the workflow variables are stored under the variables attribute in the Work Item view, which results in an additional variables. prefix being required in the attribute path.
Because of this nesting of the user view attributes, you cannot use a standard user form with the Work Item view without modification. However, you can define a work item form that references the user form with the base context option.
<Form name=’WorkItemForm’> <Include> <ObjectRef Type=’UserForm’ name=’Default User Form’/> </Include> <FormRef name=’Default User Form’ baseContext=’variables.user’/> </Form> |
Although in practice the work item form requires additional fields for buttons such as Approve and Reject, you may not want everything displayed by Default User Form displayed in the work item form. Typically, you can factor out the fields in the user form into a form library that can be referenced by both the user forms and the work item forms.