Issue Field Value Dependencies

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).

You must login to see this link. Register now, if you have no user account yet.

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

Rule	Description	Applicable for
Set	Set child field value to parent field value	All fields
Default	Set child field value to parent field value, but only if the child field is empty	All fields
Least	Set child field value to the least of parent and child field value	All fields
Greatest	Set child field value to the greatest of parent and child field value	All fields
Fraction	Set each child field value to a fraction of the parent field value	Numeric fields
Subset	Remove all child field values that are not also parent field values	Multiple choice fields
Superset	Add missing parent field values to the child field values	Multiple choice fields
Close recursively	Upon close of a parent, also close all children recursively	Status
Close restricted	Deny closing a parent, as long as not all children have been closed	Status

Standard Aggregation Rules

Rule	Description	Applicable for
Minimum	Set parent field value to the minimum of all child field values	All fields
Maximum	Set parent field value to the maximum of all child field values	All fields
Sum/Total	Set parent field value to the sum/total of all child field values	Numeric fields
Average	Set parent field value to the average of all child field values	Numeric fields
Union	Set parent field value to the union of all child field values (all distinct field values that appear in any child)	Multiple choice fields
Intersection	Set parent field value to the intersection of all child field values (all common field values that appear in every child)	Multiple choice fields
Mean status	Set parent status to a mean/average status of all children	Status
Close upwards	Close the parent, after the last child has been closed	Status

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.

Distribution rule	Aggregation rule	Effect on changing the parent value
Set	Any, except Sum/Total	Overwrites child values with parent value
Default	--	Overwrites empty child values with parent value
Least	Maximum	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.
Greatest	Minimum	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.
Fraction	Sum/Total	Changing the parent value will set the child values to “Parent value/number of children”
Subset	Union	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.
Superset	Intersection	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.
Close recursively	Close upwards	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.
Close recursively	Minimum	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.

Examples

Numeric Field Type Examples:

Aggregation Rule	Distribution Rule	Change	Result
Maximum	--	Child values (1, 3, 5, 7) ↑ to (1, 3, 5, 8)	Parent Value changes from 7 to 8
Maximum	Least	Parent value changes from 8 to 7	child value changes from 8 to 7

Set or Choice Field Examples:

Aggregation Rule	Distribution Rule	Change	Result
Union	Subset	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)
Intersection	Superset	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)

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.


For example:

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.

For example:

• 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.