Tracker Inheritance

Trackers (similar to Classes in object oriented programming) can be derived from/extend base/template Trackers:

• Structure, Relations and Behavior of the base/template Tracker are inherited by derived Trackers.
• Trackers only support single inheritance, but hierarchically over multiple levels.
• Inherited settings can be overloaded/overridden in derived Trackers.
• Derived Trackers can add own/additional Structure, Relations and Behavior.
• The depth of the inheritance hierarchy is unrestricted.

Template Tracker

Whether a Tracker can be used as base/template for other trackers, is defined on the General tab of the Tracker settings.

E.g.: Make the Approvals Tracker from the Forking sub-processes from processes (work items) example available as template tracker:





To create a new tracker, that is derived from a base/template Tracker, click on New Tracker on the Trackers page of a project, and the choose the Template for the new tracker:

In our example, the template tracker (Approvals) is from the same project (Workflow Demo), where we create the new derived tracker. But you can derive new trackers from any template tracker in any project, where you have access to.

To let the new tracker inherit the configuration of the Template tracker. Leave Inherit template configuration checked, otherwise your new tracker will get a snapshot copy of the Template tracker's current configuration, but without inheritance.

You can also (optionally) mark the new derived tracker, to be Available as template tracker itself.

This allows tracker template/inheritance hierarchies of unlimited depth.

The Tracker Inheritance is also visualized as blue Generalization arrows from the derived tracker to the template tracker in the Tracker Configuration Diagram.

E.g: Configuration Diagram on the Trackers page:

All the General settings of a Tracker:

• Name
• Key
• Description
• Inbox
• etc.

are specific for a Tracker instance.

But for Trackers derived from a Template, the

• Permissions
• State Transitions
• Fields
• Escalation rules
• Notifications (partly)
• and Views

are inherited from the Template.


Changing the Template of existing trackers is also possible:

• Changing the Template to None
  This will detach the tracker from the template: All settings, that were previously inherited from the Template, will be materialized (copied) to the tracker.
  Further changes of the old Template will have no more effect on the detached tracker.
• Changing the Template to (another) Tracker
  Caution: This will delete all existing inheritable settings of the tracker (see above), before attaching the tracker to the template.

Inheritance

Inheritance means, that a derived tracker does not have copies of template settings, but implicitly uses the inherited settings of the template/base tracker directly.

Changes of template settings have immediate effect on all directly or indirectly derived trackers.

Inheritance, even over multiple inheritance levels, does not have a negative impact on performance.
Quite the contrary: Sharing inherited settings, drastically reduces the amount of required memory.

Overriding

Derived trackers can override inherited settings and also add new specific settings, that are not present in the Template.

Overriding simply means, that you change the value of an inherited setting in the derived tracker to a different value, than in the template.


E.g. Override the Permission Tracker - Subscribe of role Stakeholder:




In the Permissions example, each checkbox (permission per role) is a setting, that can be overridden individually.

For Fields you can override individual settings like

• Position
• Label
• Title
• List(able)
• Mandatory
• Min./Max. value
• Distribution/Aggregation rule

but also individual

• Choice Options
• Reference filters
• Allowed/Default values for a specific status
• Permissions
  • for a specific status
  • for specific participants/roles

Note: You cannot delete inherited Fields in a derived tracker, but you can override the field's Permissions, so nobody can see/use the field (Do not forget to also override Mandatory to None, if necessary).


To re-activate inheritance for a previously overridden setting, simply change the value in the derived tracker back to the value of the template.

Upon Save of inheritable settings in derived trackers, CodeBeamer will compare each setting with the appropriate setting the template tracker:

• Only settings, where the value is different than the template, will be stored (overridden) on the derived tracker.
• Settings, where the the values in derived tracker and template tracker are identical, are not stored (overridden), because the template setting can be re-used.
  • This implicitly also means, that any changes of these settings in the template are immediately reflected in derived trackers.

Changing values (concurrently) on the Template tracker and on derived trackers, can (per definition) never cause conflicts, because values set on derived trackers always override (have precedence over) values set on the template.

But there are situations, where a wrong order of definitions can cause unexpected behavior:

1. You change an inherited value on a derived tracker, which stores this change as a value override.
2. Then you make the same change on the template tracker.

Although the value in the derived tracker and the template value are now identical, the value of the derived tracker is not inherited, but still overridden.

To re-activate inheritance, you would have to edit (and save) the derived tracker configuration again.

Template Projects

Instead of marking individual trackers to be Available as template, you can also mark whole Projects to be Available as template on the Project Administration General tab.

E.g.: Make the Forking sub-processes from processes (work items) example project Available as template:





You can then create New Projects based on the template project:




and select, which components of the template project to copy or inherit:




For each Work/Configuration Item Tracker, you can decide individually:

• whether to have such a tracker in the new derived project, and
  • whether to Inherit or Copy the template tracker configuration.

E.g: The Trackers Configuration Diagram of the project WorkflowDemo 2, which was derived from template project WorkflowDemo :





Please note:
There is no persistent inheritance link between Projects, only between individual Project Trackers!

Reference Inheritance

The example diagram above, also shows an important feature regarding the inheritance of references between trackers:

• Active Reference Inheritance with Redirection

That is defined as:

• If a tracker A' is derived from a template A,
• where the template tracker A has a reference X to another tracker B (A -> B),
• and there is also a tracker B' in the same project than A', where B' is derived from B,
• then the inherited reference X' (A' -> B) will be automatically overwritten to be X' (A' -> B').

For example:
In the Forking sub-processes from processes (work items) example template project:

• Approvals has a field Subject, that references Processes.

The project WorkflowDemo 2, which was derived from template project WorkflowDemo, has

• an own Approvals tracker, derived from WorkflowDemo -> Approvals
• and also an own Processes tracker, derived from WorkflowDemo -> Processes

Therefore the field Subject of the Approvals tracker in project WorkflowDemo 2 will be automatically overwritten, to refer to the Processes in project WorkflowDemo 2 .


That Reference Inheritance with Redirection will be also applied to other inheritable tracker settings:

• Dynamic/Relation based dependencies between work/configuration item reference fields
• Update Referring Items
• Create new Upstream-Downstream referring items