If you have parent/child hierarchies of configuration items or issues, you can now define dependencies between parent field values and the appropriate child field values (recursively). If, for example, you wish to ensure that a parent issue is not closed until all the child-issues (children) are closed, then this dependency can be managed using one of the distribution rules defined in this document. Similarly if you wish to define the parent issue's "Spent Hours" as the sum of the children's "Spent Hours" you can define this aggregation rule, too.
Parent field value updates can be distributed to children (recursively) and child field values can be aggregated into parent field values (recursively).
This is controlled in the distribution and aggregation rules shown in Category/Tracker → Customize → Fields for each applicable field:
The set of applicable distribution and aggregation rules for a field depends upon the field and its type.
Standard Distribution Rules
Set child field value to parent field value
Set child field value to parent field value, but only if the child field is empty
Set child field value to the least of parent and child field value
Set child field value to the greatest of parent and child field value
Set each child field value to a fraction of the parent field value
Remove all child field values that are not also parent field values
Multiple choice fields
Add missing parent field values to the child field values
Multiple choice fields
Upon close of a parent, also close all children recursively
Deny closing a parent, as long as not all children have been closed
Standard Aggregation Rules
Set parent field value to the minimum of all child field values
Set parent field value to the maximum of all child field values
Set parent field value to the sum/total of all child field values
Set parent field value to the average of all child field values
Set parent field value to the union of all child field values (all distinct field values that appear in any child)
Multiple choice fields
Set parent field value to the intersection of all child field values (all common field values that appear in every child)
Multiple choice fields
Set parent status to a mean/average status of all children
Close the parent, after the last child has been closed
A field can have no rules at all, either an aggregation rule or a distribution rule, or both.
A field with an aggregation rule, but without a distribution rule, will only be editable as long as the item/issue doesn’t have children.
As soon as children exist, an aggregated field without a distribution rule will become read-only.
For static choice fields: Minimum, Maximum, Least and Greatest will be determined according to the order of field choice values, as defined via Category/Tracker → Customize → Choice Lists .
If the internal order of choice values is logically descending (like the standard CodeBeamer Severity values), in order for an aggregated field to show the logically highest field value, the aggregation rule must be Minimum.
Recommended Combinations of Distribution and Aggregation Rules
If a field has both an aggregation rule and a distribution rule, care must be taken that both rules do not conflict.
Choose the aggregation rule first and then decide which distribution rule (if any) is appropriate.
Effect on changing the parent value
Any, except Sum/Total
Overwrites child values with parent value
Overwrites empty child values with parent value
No child value may be larger than parent value, so if a parent value is reduced, if a child value used to exceed the new parent value, the child's value is now set to the new parent value. Subsequent increases in the parent value have no effect on child values.
No child value may be smaller than parent value. Increasing the parent value also increases the child values that used to be lower than this new parent value. Decreasing the parent value has no effect on child values.
Changing the parent value will set the child values to “Parent value/number of children”
All child values must be a subset of the parent value. Removing a parent value will also remove that value from all child value lists. Adding a new parent value has no effect on child values.
All parent values must also be contained in the child value lists. So adding a parent value will also add that value to all child value lists. Removing a parent value has no effect on child values.
If all children are closed, the parent should also be closed. So closing the parent will also close all children. State transitions other than close are neither distributed nor aggregated.
Similar to above, but child state transitions are aggregated into parent state transitions (including close)
These aggregation and distribution rule recommendations don't have to be followed, but the resulting effect may be difficult to predict if the suggestions are ignored.
For new trackers, the recommended aggregation and distribution rules will be placed by default with the corresponding fields. In existing trackers, the distribution and aggregation functions are available, but there is no automatic rule setting. The rules will be implemented only on new issues.
Numeric Field Type Examples:
Child values (1, 3, 5, 7) ↑ to (1, 3, 5, 8)
Parent Value changes from 7 to 8
Parent value changes from 8 to 7
child value changes from 8 to 7
Set or Choice Field Examples:
Child Value sets change from (1,2,3) & (3,4,5) to (1,2,3) and (4,5,6)
Parent Value sets change from (1,2,3,4,5) to (1,2,3,4,5,6)
Child Value sets change from (1,2,3) & (2,3,4) to (1,2) and (1,4)
Parent Value set changes from (2,3) to (1)
Dynamic pick-list fields / Dependencies between different fields of the same item (Cascading fields)
Besides the dependencies between the same field of parent and child items in a tracker, which are controlled via the field's Aggregation and Distribution rules, CodeBeamer (since CB-7.0) also allows to define dependencies between different Choice/Country/Language/Reference fields (of the same item).
Static field value combinations
E.g. The (values of the) Language field of a Contact should depend on (the values of the) Country field:
To define the actual/allowed Country/Language field value combinations, click on "depends on Country" in Layout and Content of the Language field:
In the popup dialog, you can then define the allowed value combinations for the combined fields:
E.g. English is spoken in any country, the official language in Germany and Austria is German, and in Switzerland the official languages are German, French and Italian:
If you now create or edit a Contact, the available values for Language will depend on the selected Country, e.g. for Switzerland:
Field dependency chains can be of any length, e.g. Field C depends on field B, which depends on field A.
On the GUI, dependent/cascading fields should be placed together, in the inverse dependency order: Dependent fields after the fields they depend on.
Dynamic/Relation based dependencies between work/configuration item reference fields
Since CB-7.7.1, CodeBeamer also allows to define dependencies between work/configuration item reference fields, based on relations (defined via reference fields) of the underlying trackers.
A reference field named Change Request:
referring to items from the Change Requests tracker:
and a second reference field named CR Tasks:
that depends on Change Request and refers to items from the Tasks tracker:
If you now click on "depends on Change Request" in Layout and Content of the CR Tasks_ field:
There is a new selector for dynamic value combinations, in addition to the static field value combinations explained earlier.
This selector lists all source trackers for the "Depends On" field (in our example, there is only one: Change Requests).
If you select a source tracker, a new entry will be added to the dependency matrix:
That new entry allows to select one or more constraints for the dependent field (CR Tasks in our example).
These constraints are the defined relations between the selected source tracker of the Depends On field and the possible source trackers of the dependent field (in our example there is only one: Tasks).
If you look at the (extract of) the Tracker Class Diagram:
you will see that there is a relation between Tasks and Change Requests via the reference field Subject (of Tasks).
Because our point of view here is from Change Requests to Tasks, this reference will be shown as "Tasks for Subject" (Tasks referring to us (Change Requests) via their Subject field).
The resulting dynamic field value combination reads as:
If the selected Change Request is an item of the Change Requests tracker,
then the CR Tasks (which are implicitly items of the Tasks tracker) must refer to the selected Change Request via their Subject reference field.
If there are multiple possible source trackers for the Depends On field, then you should define constraints for each of them.
You can also have cascading reference fields referring both to the same source tracker.
The first field refers to a Functional Unit which is a top-level item (via a specific view/filter) in a Components tracker
The second field refers to a Main Process, which is a sub-item (child) of the Functional Unit in the same Components tracker.