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:
Starting from codeBeamer 8.1 the Template dropdown only allows to select templates with the same Tracker type.
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 withoutinheritance.
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.
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.
Starting from codeBeamer 9.4 changing the Template requires the user's signature.
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.
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 PermissionTracker - 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
but also individual
Allowed/Default values for a specific status
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:
You change an inherited value on a derived tracker, which stores this change as a value override.
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.
Instead of marking individual trackers to be Available as template, you can also mark whole Projects to be Available as template on the ProjectAdministrationGeneral tab.