Child pages
  • How to Customize the Bugs Workflow
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Deskzilla application allows users to customize the issues workflow by defining a set of actions which can be applied to an issue or a number of issues.

The actions (such as, for example, Resolve As, Reassign, Close, etc) are defined in the XML file and can be accessed through the Workflow combo box on the Issue Toolbar. Below is the explanation of the XML file structure, which will allow you to create new actions and modify the existing ones.

File structure

To define actions a set of tags is used. See below for detailed explanation.

Conditions


Issues must meet specific conditions to be eligible for the action. These conditions are defined using the condition element.

"Sample condition"
<condition>
  <name>Open</name>
  <filter>status in (UNCONFIRMED NEW ASSIGNED REOPENED)</filter>
</condition>

The Condition element has two child tags both of which are mandatory:

  • The name tag defines the name of the condition by which it can be referred to later
  • The filter tag defines the condition itself. The syntax is same as in the Query Builder so the condition can be created in the Query Builder and then copied to the XML.

The Workflow.xml file uses the same syntax as the Query Builder for conditions definition, so the statements can be created in the Query Builder and then copied to the XML file.

Actions

The action element is used to define the action itself.

"Sample action"
<action>
  <name>Resolve As</name>
  <condition>Open</condition> <!-- <filter>status in (UNCONFIRMED NEW ASSIGNED REOPENED)</filter> -->
    <set>
      <!-- action script -->
    </set>
</action>

It consists of thee mandatory sub-elements:

  • The name tag, which defines the name of the action shown in the UI components (such as Workflow drop-down list).
  • Action applicability condition, which defines which conditions an issue must meet to be eligible for the action. Action applicability can be defined either by referring to the condition defined earlier or by specifying a filter statement using the filter tag and the same syntax as is used for the condition definition.
  • The set tag, which defines the action script run when the action is applied. The script may contain both defined actions (for example, change the status value to Closed for the Close action) and actions, which require user input (for example, get the user comment when the issue status is changed).

Optionally an action may contain the windowId child tag, which defines the window identifier used to refer to the visual properties of the action window (such as size, position, etc). This identifier can be used to apply one window configuration for several actions. If not specified the action name is used to generate the identifier.

Below is the explanation of the Action script syntax.

Action script

Action script defines a number of changes that are made to the issue as a result of the action (the action that defines no changes does not make sense, but is valid). Each script element defines which field of the issue is altered and how.

"Sample modification"
<attribute>
  <name>status</name>
  <value>RESOLVED</value>
</attribute>

Below is the description of tags used to define the fields change.

value: Change field to predefined value

"Sample modification"
<value>RESOLVED</value>

This tag is now applicable only to enumeration fields (such as status or assignee). The content contains textual presentation of desire value. This modification is shown to user on action window but can not be modified.

askAddTextElement: Add text value

"Add comment"
<attribute>
  <name>comments</name>
  <askAddTextElement>$(bz.form.label.comment!mnemonic=o):</askAddTextElement>
  <checkbox>$(bz.form.label.privateComment!mnemonic=p)</checkbox>
</attribute>

Now this modification can be used only to add comment to a bug. It should be used as shown in the example.
Content of askAddTextElement defines label text. Content of checkbox defines text shown near to checkbox "private comment". Both can be replaced with any readable text.

askAddNotEmptyTextElement: Add not empty comment

This modification is same as askAddTextElement\ but enforces to provide comment. Action can not be finished until comment text is empty.

askReference: Choose single enumeration value

"Sample combobox"
<askReference>$(bz.field.Resolution!mnemonic=r):</askReference>
<exclude>N/A</exclude>
<exclude>DUPLICATE</exclude>

This modification allows to choose value for single enumeration field. Content of askReference allows to provide label text. On action form this modification is shown as combobox.
This modification supports additional exclude tags. Each of them allows removes one value from combobox variants.

askEditableReference: Choose or type in single enumeration value

This modification acts as askReference\ modification. The difference is that user may type in new value. exclude tags aren't supported for this modification.

askString: Change text field

"Sample change text field"
<askString>$(bz.field.DuplicateOf!mnemonic=d):</askString>

Allows to change value of text field when action is performed. In action window presented with text field.

  • No labels