Rule examples

Examples of creating rules are listed below.

Count the number of times defects are re-opened

For purposes of improving quality processes, you can track the number of times are re-opened after being set to Fixed.

  1. Create a 'Reopen Counter' field of type Integer in the Defect entity. For details, see Customize fields.
  2. Create a new rule for the Defect entity.
  3. Action details. Select the following values in the Action tab.

    Setting Value
    Action 'Set field value'
    Timing

    'When saving an entity'

    Field Select the 'Reopen Counter' field.
    Increment value by 1
  4. Condition details. Define the following conditions in the Condition tab.

      Field Operator Value
    #1 Phase Current = Opened
    AND
    #2 Phase Orignal ≠ New

Record the Last Modifier of a manual test

It can be useful to know who made the last change to a manual test. You can create a rule to record this information in a user-defined field. The field will be populated when specified changes are made to the manual test.

  1. Create a 'Last Modifier' field of type User in the Manual Test entity. For details, see Customize fields.
  2. Create a new rule for the Manual Test entity.
  3. Select the following values in the Action tab. Use the screenshot below for assistance.

    Setting Value
    Action 'Set field value'
    Timing

    'When changing a value'

    Note: Select the fields upon which a change to their values will record a change to the 'Last Modifier' field.

    Field Select the 'Last Modifier' user-defined field.
    Set value '[Current User]'

Combining Lookup lists for use under certain conditions

Create a rule that adds additional Lookup list values to a defect's Severity if the defect's release is 2.00.

For example, the available Severity values for release 1.16 might be 1-Low, 2-Medium, and 3-High. For release 2, additional severity values were added, so the complete list is 1-Low, 2-Medium, 3-High, 4-Very High, and 5-Urgent.

Prerequisites

Create a new Severity list that contains the values 4-Very High, and 5-Urgent. Call it Severity2.

Create a rule to define the circumstances when additional list values are needed

Action: Use an additional Lookup list for the defect's possible Severity values, in addition to the original Lookup list's values. Select Severity2 in the List field and if desired, select individual Sublist values.

Condition: If a defect's Release is 2...

Result: 

  • In the ALM Octane UI, if you open any defect whose Release is 2, you will be able to choose from all five Severity values, not just from the original three Severity values. 

  • When filtering by Severity, all five values are available.

Back to top

Setting a subset of a Lookup list

Depending on the current team, certain item origins for defects are not available. For example, if a certain team only works with ALM and ALM Octane, the item origins for that team's defects cannot be Service Anywhere or Jira. You can create a rule that makes only a sub-list of the current lookup list available, based on the team.

Condition: If the Team field is a specific value...

Action: Select the Item Origin values that are relevant to that team.

Back to top

Making fields required

Make the testing tool type required to prevent empty values for automated tests.

Condition: If the Testing tool type field Is Empty...

Action: The Testing tool type field is required.

Back to top

Setting default field values (Set Field Value)

To make sure each manual test is assigned to an application module, set the Application modules field value to a default application module for all empty statuses.

Condition: If the Edit mode for the test is New, it means the test was just created and...

Action: Set the Application modules field to General.

Back to top

Setting a value when a related item changes (Set Field Value)

Automatically set a user story to done when all its child tasks are done (DoD).

  • Condition: The number of child tasks with the phase New or In Progress is zero. Use the following values to formulate this condition:

    Operand "Child task count"
    Operator {filter = Phase: ( New, In Progress ) }
    Equals 0
  • Action: Set the Phase field for the user story to Done.

Consider the following: 

  • The transition from current phase to Done is possible based on the workflow. For example, if the phase of a user story is New, it cannot be promoted to Done.

  • The Set Field Value rule does not validate to make sure required fields have values. For example, if Severity is a required field when promoting to Done, the promotion rule will still update the phase to Done even if Severity is blank.

  • The rule overrides manual changes. So once you define this rule, there are no exceptions. You cannot, for example, manually modify user story's phase if all its related tasks are done. The next time the rule runs, the phase will be reset to Done.

  • When the rule runs, its actions are performed by an internal system user.

Back to top

Triggering webhooks (calling a URL)

For webhook integration with another application when an entity is created, deleted or updated, you can use a Trigger Webhook rule to POST a request to an endpoint URL. The service at the URL receives the call and processes the request.

Condition: <None>

Actionable upon: New, Update, Delete

Action: POST ALM Octane entity information to the endpoint URL:  http://myServer:8081/myAPI.

For details on setting up Trigger Webhook rules to POST information to endpoint URLs as a result of an event, see Trigger webhooks for other applications.

Back to top

Switching forms

When a tester creates a defect to report a bug, organizational policy dictates that the tester be able to view and edit the following fields: Description, and Severity.

Similarly, when a developer starts fixing a defect, the developer must be able to view and edit the following fields:  Fixed on, Fixed in Build, and Owner.

Define two rules:

  • Rule 1: Sets a form for developers.

    Condition: If the team is the Developer team...

    Action: The form for developers is used.

  • Rule 2: Sets a form for testers.

    Condition: If the team is the Tester team...

    Action: The form for testers is used.

Back to top

Send an email when a item's attributes are updated

When a user story, defect, or other item changes its status, you may want to be notified that such an item has been updated.

To do this, you define it in one the following ways:

  • If you want to be notified of any change in a specific field - such as the phase of an item - select Is Modified as the operator for the field.

  • If you want to be notified of a change in specified field to specific value - such as a defect moving from Opened to Fixed - set the Original = field to the previous value and the regular operator to = for a new value.

Back to top

Prevent developers from closing a defect, while all other users can

Developers should not be able to close defects, so we can create a workflow rule that blocks this transition.

We recommend you create the rule from the Workflow tab for the entity. This way, the From and To phases for the transition are already entered for you. Select the transition between Proposed Closed and Closed, and add a rule using the Rules panel.

Condition: If the Current User Role includes Team Member...

Action: Block transition from Proposed Closed to Closed.

Back to top

Allow testers to open defects on some releases but not others

Testers work on different releases.

First, ask your space admin to make sure that the tester has create/edit permissions for defects. For details, see Assign roles and permissions.

Then we add an Alert User rule with a condition that lists the releases for which the tester cannot update defects.

If the condition in the rule evaluates to true, the rule alerts the user that the updates violate the specified condition and prevents all updates to the defect.

Action: Alert the user when creating, modifying or deleting a defect if the condition indicates a problem (meaning, the condition evaluates to true).

Condition: If the Current User Role includes Tester, and Release equals a forbidden release, the condition evaluates to true. The user is alerted and updates are prevented.

Back to top

See also: