A query consists of one or more conditions that must be met by each work item in the result set.
You can combine and nest conditions by surrounding them with AND and OR elements. Each condition references a work item attribute, an operator, and one or more values. The meaning of multiple selected values depends on the operator: for positive operators like is, the meaning is OR. For negative operators like is not, the meaning is AND. The following two examples illustrate this concept.
Example 1: Setting the Status attribute
is New OR is Reopened
Example 2: Setting the Status attribute
is not New AND is not Reopened
You can also specify multiple values for attributes of a simple type like a string or numbers by using a comma-separated list.
Example 3: Setting the ID attribute
is 53 OR 110 OR 129 OR 216
If you do not select or enter a value for an attribute condition, the query engine ignores the condition. An empty condition is the equivalent of matching all possible values of the attribute.
Most value sets are configurable and can change over time, meaning that your queries might become stale. Variables represent a value or value set that can change over time or adapt to the context in which a query is run. For these reasons, variables offer a way to create queries that stay valid over time and can be shared among users.
In the user interface, variables are represented as check boxes that are located above the value area in the query editor sections. Example 4 shows the Unresolved and Resolved variables for the Status attribute.
Example 4: The Unresolved and Resolved variables for the Status attribute
You can use variables like any other value. If variables are combined with other variables or values, the same semantics apply as described. In the previous example, if you select the Unresolved variable and the Deferred value, it means that the Status attribute condition is "Unresolved OR Deferred" for the is operator.
|Status||Unresolved||When you define a workflow, each state can be
assigned to one of three groups:
in progress, or
closed. The Unresolved variable selects all states that belong to the
in progressgroups at the time the query is run.
|Status||Resolved||When you define a workflow, each state can be
assigned to one of three groups:
in progress, or
closed. The Resolved variable selects all states that belong to the
closedgroup at the time the query is run.
|Users||Current User||The Current User variable selects the authenticated user at the time the query is run.|
|Filed Against||Related to Current User||A category belongs to a project or one or more
team areas. The Filed Against variable selects
all categories that are associated with a team area that the authenticated
user belongs to at the time the query is run. This variable can be
thought of as
my team areas.
|Planned For||Current Iteration||When you use the is operator
with the Current Iteration variable, the query
selects the first iterations that have the
release scheduledflag set when a search is performed up the hierarchy starting at all leaf iterations that are set as current in the project area. The current iteration corresponds to the iterations that are shown as current in the work item editor.
When you use the is part of operator with the Current Iteration variable, the query uses the selected iteration as the root and includes all of its children in the project area.
|Creation Date||Click Relative date to
specify a point in time or a time range that corresponds to the time
the query is run.
When you use the after (including) or before (including) operator, the variable returns the time that the query is run plus the offset. For example,
the is and is not operators,
the point in time is calculated as described for the Planned
For attribute, but the variable returns a time range that
includes that point in time and uses the time unit that you select.
For example, if today is 3 November 2015, the query conditions that
are listed next have the following meanings.
Note: There is no time zone correction for the client when you run the following query:
Parameter variables are a special type of variable feature that makes queries more flexible by promoting reuse across contexts and users. A parameter variable is a condition that allows users to choose its values each time they run the query, which enables reusing a query in different contexts. For example, queries with changing user groups, date ranges, work item relationships, and severities can be consolidated by using parameter variables. When a condition in a query is known to change across query calls, it is advantageous to define it as a parameter variable.
For example, a query that finds
All stories that are resolved by prompts for a IBM® Engineering Workflow
Management user and
some text input before the query runs.
Example 5: Running a parameterized query on the Resolved By and Full Text attributes
You do not need to provide values for all parameter variables. If you do not provide a condition value, the condition is ignored and the query runs without it, just like queries that you run from the query editor.
- Created By me with $Severity and $Priority...
- Resolved By $Team in $DateRange...
- Open SCM work items by $Tag...
- All Resolved By $User...
- All open dashboard widget work items by $Severity, $Priority, and $Type...
Engineering Workflow Management appends an ellipsis (...) after the names of parameterized queries in the user interface to indicate that you need to provide further input before the query runs.
The Unassigned value
Some work item attributes can be empty or have an Unassigned value that is not part of the attribute's configurable value set. The Unassigned check box, which is in the variables area for an attribute, enables querying for this empty value. You can find examples of the Unassigned value in the Owned By and Planned For attributes. By selecting the Unassigned value, you can create a query for work items with no owners set or that are not planned for an iteration.
Example 6: The Unassigned value in the Owned By and Planned For attributes
Attribute groups (Eclipse client only)
You can use attribute group controls to specify a condition for a set of attributes of the same type without having to add them individually and select the same values for each of them. Attribute groups exist for User and Timestamp attributes. You join the individual attribute conditions by using OR.
Example 7: An attribute group for the User attribute
the example, the User attribute condition is
set to find
work items that are created by, modified by, owned
by, OR resolved by the current authenticated user.