###

| Summary |  | Definition |  | Restrictions |  | Requirements |  | Controls |  | Actions |

Rule Id: |  |  |
: |  |  | |
: | <SUB wfDescription>
: | >
| >
| > Special Purpose - Only run from events or other rules using autochange create fuctionality, where this rule is specifically selected.
| >
Current Attributes

The Definition attribute defines the cases when a rule is going to be used.
Each time that details about an are requested or changed, the state of the is compared against the state definitions of the rules in your system. If a match is made, then the attributes of this rule are used to control how data can be accessed or modified.

The State Definition defines the cases in which a rule is used. It is defined by a filter definition, which tells the system when the rule should be applied.
The Pre State Definition attribute is used only when a is being modified. Therefore, it has no effect on a New , which has no pre state.
It is compared against the state of the before it was modified, as part of the rule check.

Example 1:

State Definition: Status=[Closed], AssignedTo=[DevGroup]

This definition sets up a rule which will affect workflow for any that is in the "Closed" status and is assigned to a member of the DevGroup group. This could be used for controlling who can access a (use access attributes), adding contraints to any that is being changed to this state (requirement attributes), controlling how details are displayed for this (control attributes), or triggering an action when the hits this state (action attributes).

Example 2:

Pre State Definition: Status[Open,Assigned]

Additionally, you could restrict this to modifications where the was in a specific state, such as if the Bug was previously Open or Assigned.

The Restriction attributes can be used to allow or deny permission for users to move an issue to the defined state.

Example 1:

Deny Group = [Dev]

This restrict the Dev team from accessing issues defined by this rule.

The Requirement attributes define constraints that are tested before any changes to a are accepted. Contraints are defined by a filter, which defines the requirement.
If a change to a is requested which causes the state of a to match the rule definition, the requirement attributes are tested. When a requirement fails, the change is ignored and a workflow error results.

A Pre Requirement is a test that is made on the state of a , before the change request.
A Post Requirement is a test that is made using the potential state of the , if the change is accepted by the system.

Example 1:

Post Requirement: LoggedIn=[DevGroup]

This post requirement sets up a requirement for this rule that ensures any user making this change is a member of the DevGroup

Example 2:

Pre State Requirement: Status[Open,Assigned]

Additionally, you could define a check that requires any change of this type must have been from a previous state where status was Open or Assigned.

The Control attributes will control changes that are made to the Edit menus when you modify a that matches the rule definition.

A Flow Control attribute will limit the values that are available in selection lists on the edit pages.
A Field Control attribute controls permissions to fields and select fields as mandatory. These controls supercede those defined in the normal admin field controls.

Example 1:

Flow Control: Status=[Open,Assigned]

This flow control restricts a user to changing the Status state to "Open" and "Assigned". This is useful if you want to restrict users from moving issues to the closed state.

Example 2:

Field Control: Project=[RO]

This field control sets the Project field to Read Only, so that it can not be changed.

Example 3:

Field Control: Project=[H]

This field control hides the Restricted field.

The Action attributes define actions that are triggered if a is changed and matches the state defined by the rule definition.

The Notify List attribute will perform a one-time notification to users any time a change results in a that matches the rule definition.
The AutoChange attribute allows you to automatically change data fields.

Example 1

Notify = [<SUB bs.mEnteredBy>]

This action causes a notification to be sent to the user that originally entered the issue. This is a one-time notification.

Example 2

AutoChange [Notify List=<SUB bs.mNotifyList>;peter]

This action adds peter to the current notify list for the issue.

Example 3

AutoChange [Comment=new String("Current status is : ") + mCurrentStatus + new String(" and current value of custom field with id 3 is : ") + mUserFields.get(new Integer(3))]

The OGNL option allows you to create a complex value at runtime, using java syntax and the field values for the being manipulated.
In this case, we are simply adding a comment with the value of status and a custom field, when the action took place.
There is a Test button that you can use to test the OGNL syntax against a .

| :