Rules customize the ALM Octane user interface and control actions users can perform. The rules enable administrators to implement and enforce organizational, departmental, and group policies for the workspace. Rules perform these activities without explicit user intervention.
Rules contain an action and usually a condition. You set the action that should occur when the defined condition is true.
Most actions affect fields. These actions generally affect organizational policy. You can:
Some actions affect forms, such as enabling users to select different form layouts for adding and editing entities. These actions affect usability.
Conditions, when met, cause the rule's action to be performed. Conditions can be based on a value of a field or on the group associated with a user.
You don't have to specify a condition, but you can. If you don't specify a condition, the rule's action is always performed.
ALM Octane evaluates complex conditions only until the condition evaluates to either true or false, and then does not continue evaluating the rest of the complex condition.
Tip: Conditions can evaluate to false if ALM Octane encounters a field in a rule definition that it cannot process because the field does not exist. Sometimes this is because a field was removed from the project.
However, there are situations where this is not an error, but part of the logic necessary to implement your organization's policy.
Think about the rules you need. What use case should your rules handle? What should the rules achieve?
For details, see Define and run rules.
Define what actions to perform in the Action tab.
In this tab, you can also:
For details, see Define rule actions.
Define when actions are performed using conditions in the Condition tab.
For details, see Define rule conditions.
Save the changes.
Once saved, expect the rules to run in real-time.
|Switching Lookup lists||
You can create a rule that assigns different lookup lists for defects' severity based on the release. For example, the available severity values for release 1.16 might be 1-Low, 2-Medium, and 3-High, while for release 2.00, the available severity values might be 1-Low, 2-Medium, 3-High, 4-Very High, and 5-Urgent.
Condition: If a defect's Release field is 2.00...
Action: Use a different lookup list for the defect's possible severity values (such as Old_Severity_Values, New_Severity_Values).
|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.
|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.
|Setting default field values||
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.
|Calling a URL||
To support advanced workflow use case scenarios and integrate with external applications, you can use Call URL to trigger a third party script embodied in an endpoint URL.
Actionable upon: New, Update, Delete
Action: Call a script at the http://myServer:8081/myAPI URL.
For details on setting up rules that call URLS, see Enabling and handling rules that call URL scripts.
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:
|Send an email when a item's attribute's 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: