STATUS Field

The STATUS Field

The STATUS field has several properties that separate its functionality from other fields, including other inbuilt fields. As its name implies, it is used to track the status of issues as they transition through the workflow you configure. The handling of the STATUS field has these properties –

  • The STATUS field is used on issues to manage workflow. There is a complementary field available for repeating rows named RELEASE_STATUS. Both fields share the same set of values and the same workflow. The values for both lists are defined within the STATUS field list
  • You may set up workflow around the transitions of the states of an issue between the STATUS values. This workflow may be set up role-by-role or product-by-product. It may also be set up globally and inherited by different business areas and projects, or it can be set up individually within any business area and project combination
  • The STATUS field is unique in that each value (such as Open or Closed) is given two security permission keys, one for adding and one for updating issues. If the user does not have write permission to a STATUS add value, then the value will not be displayed in the STATUS list. If the user does not have permission to the key when updating an issue, they will still see the value in the list, but they may not select that value from the list and update the issue. They may still edit and update the issue with other STATUS values to which they do have permission. They simply cannot update the issue to a value of the STATUS field to which they do not have permission. This functionality is desired as a user may have permission to update an issue, but they may not have permission to update to an individual STATUS value. When in query screens, the user will see all STATUS values, irrespective of whether they have read or write permission. If you require to hide STATUS values from users, consider using an allowed value relationship, where STATUS is the child, and use this capability to control the visibility of individual STATUS values.

STATUS_TRANSITION Field

This is defined within the data dictionary as a UDF with a display type of Custom. This field provides an alternative to the STATUS field, offering a visual way of highlighting the status of an issue and showing exactly which statuses are valid to transition the issue to, obeying the workflow and status change rules. It looks like this:


The STATUS_TRANSITION field

The current status is highlighted. The user can click on any of the statuses shown, in order to transition the issue to that status. For this to operate, you should retain the STATUS field on the same layout, but you may hide this from the user, using a layout cell attribute of FIELD STYLE. For example, setting a value of display:none will hide the STATUS field list. Setting an alternate title of a space character will hide the label to the STATUS field on this form. Only the STATUS_TRANSITION field will be displayed in an editable form - actually it's a clickable field.

If the STATUS field is displayed on the same screen as opposed to being hidden, then both the STATUS and STATUS_TRANSITION fields will work in tandem.

You may alter the width and height of the field by setting a width and height (both measured in pixels) into the default value of the field in the data dictionary. Use a delimiter of a semi-colon between the values. For example, a default value of 1000;100 will set the size of the field to 1,000 pixels wide and 100 pixels high. Note that you must be precise with the syntax of the default value as no error checking is performed. If you do not provide a default value, a width of 900 pixels and a height of 80 pixels will be assumed.