WorkItem View

Used to view and modify WorkItem objects in the repository.

A WorkItem object is created whenever a manual action that is defined in a workflow process is activated. The WorkItem view contains a few attributes that describe the WorkItem object itself, as well as values of selected workflow variables copied from the workflow task.

Waveset returns information about the work items in the Work Item view under the workItem.related attribute.

Returning Information about All Active Work Items

This view provides the ability to return information about all work items that are currently active in a workflow task. By default, Waveset 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.

Example: Using the includeRelatedItems Form Property

By default, Waveset 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>

Example: Using the relatedItemAttributes Form Property

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, Waveset 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

Example: Using the includeRelatedItems Form Property

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>

Example: Using relatedItemFilter Form Property

You can specify the following filter attributes.

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’/>

Changing the Repository Lock Timeout for Work Items

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’/>

Top-Level Attributes

The following table lists the top-level WorkItem view attributes.

id

Identifies the repository ID of the WorkItem object. Typically generated by Waveset and not displayed.

name

Identifies the repository name of the WorkItem object.

taskId

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.

taskName

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.

processName

Identifies the name of the workflow process definition that contains the manual action.

activityName

Specifies the name of the workflow activity that contains the manual action.

description

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.

owner

Identifies the name of the current Waveset administrator or user that created the workflow process. This attribute is typically the name of an Waveset user. If this work item is assigned to an anonymous user, the name will have the prefix Temp:.

complete

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.

variables

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.

workItem

Specifies additional information about the work item. Contains the following attributes:

views

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.

related

Contains a list of attributes that describe the specified work item.

request

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.

requester

Identifies the user that initiated the approval.

ignoreTimeOut

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.

Using the variables Attribute

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.

Example

<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.