VDoc incorporates its own XML description language of views. We use this language to build the workflow or data stockroom views but it is also what allows us to query the VDoc data. If simple design of these XML files do not specifically request additional documentation,
VDoc incorporates a number of advanced filtering possibilities and sometimes we can be caught out when to use them. This article proposes to list and explain them.
First, to ensure that we all talking about the same thing, here's a sample XML description of a VDoc view.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definition security="false" type="activity" catalogType="0" catalog="Test1" name="TODO">
<filters>
<fieldgroup operator="AND">
<field value="$User" operator="equals" name="$activity.fulfiller" />
<field value="STARTED" operator="equals" name="dyn_Status" />
<field value="Test1" name="sys_WorkflowContainer" />
</fieldgroup>
</filters>
<view itemsPerPage="10" sortAscending="true" sortBy="dyn_CreationDate">
<column name="sys_Reference" />
<column name="sys_Title" />
<column format="datetime" name="sys_CreationDate" />
<column name="dyn_CurrentStage" />
<column maxElements="5" name="dyn_CurrentActors" />
<column format="datetime" name="dyn_CreationDate" />
</view>
</definition> This XML corresponds to an XML description of a "TODO" standard view. You can see that in this XML, some filters are already advanced, for example $activity.fulfiller.
First, you should be aware that VDoc can retrieve different types of Workflow objects:
These types are defined in the node definition as you can see in the example above.
This article will focus on filters in views, specifically the field nodes.
Our filter can include a number of operators.
| Operator | Description |
| equals | Is equal to |
| notEquals | Is not equal to |
| startsWith | Begin with |
| endsWith | End by |
| contains | Contains in |
| notContains | Not contains in |
| greaterThan | Is greater than |
| greaterOrEquals | Is greater than or equal to |
| lowerThan | Is lower than |
| lowerOrEquals | Is lower than or equal to |
The "name" and "value" attributes can contain formulas to permit more advanced filtering. We will detail them here.
In standard, the attribute "name" is assigned with the system name of the properties that you want to filter. However, there are systems names you can use for your tests.
All standard system columns can already be used:
| sys_Reference |
| sys_Title |
| sys_Creator |
| sys_Addressee |
| sys_ModifiedBy |
| sys_CreationDate |
| sys_ModificationDate |
| sys_MaxDuration |
| sys_CurrentActors |
| sys_PastActors |
| sys_AllPastActors |
| sys_CurrentSteps |
| sys_Version |
Furthermore, there are system properties that are not included to the basis but that can still be used in filtering.
| sys_Catalog |
| sys_WorkflowContainer |
| sys_Workflow |
| sys_ResourceDefinition |
| sys_WaitingActors |
| sys_Today |
| sys_Status |
There are also dynamic keys, related to taskinstances ("activity" type)
| dyn_Status |
| dyn_Delay |
| dyn_CurrentStage |
| dyn_CurrentActors |
| dyn_CreationDate |
| dyn_MaxDuration |
You can use this formula to perform a test on the connected user running the view. You can perform automatic introspection under this item.
<field name="fieldLogin" operator="equals" value="$User.login" />
Used to test the current operator on a stage.
<field name="$activity.fulfiller" operator="equals" value="$User" />
If the view is integrated into a workflow document or data stockroom (or in the case of a selector using a view in a document), it is possible to dynamically filter with the values of the current document.
<field name="Column_1" value="$Document.Value('Field_1')"/> Suppose we have to show only documents where the value of the field "Field1" is equal to the value of the field "Field2". Here's how we might proceed:
<field name="Field1" field="Field2"/>