Tracker inheritance allows users to create and maintain consistent and standardized tracker configurations settings such as permissions, fields, state transitions, notifications, and escalation rules across and within projects. Users can define common settings in a template tracker and use it to create derived trackers that inherit those settings. This reduces the effort and error of manually configuring each tracker individually. Tracker inheritance also enables users to customize derived trackers by adding or modifying the inherited settings.

A tracker is a container for work items of a certain type, such as requirements, tasks, defects, and so on. A tracker defines the properties and behavior of its work items, such as the fields, states, transitions, permissions, notifications, and escalation rules.

Template Tracker: A template tracker is a tracker that can be used as a template by other trackers. A template tracker defines the common configuration settings that are shared by its derived trackers.

Derived Tracker: A derived tracker is a tracker that is derived from a template tracker. A derived tracker inherits the configuration settings of the template tracker from which it is derived. It can also have additional configuration, such as, its own structure, relations, and behavior. Settings inherited from the template tracker can be overloaded or overridden in derived trackers.

Inheritance: Inheritance is the mechanism by which a derived tracker inherits the configuration settings of its template tracker. The inherited settings include permissions, state transitions, fields, escalation rules (if specified), and notifications.

Multiple Levels of Inheritance: Multiple levels of inheritance is the scenario where trackers support inheritance only from a single template, but hierarchically over multiple levels. A tracker derived from a template tracker can be used as a template for the next level of trackers, and so on. This can develop into a multiple level scenario with an unlimited number of levels. Configuration changes to the template tracker cascade to all directly or indirectly derived trackers.

To create a template tracker, do the following:

Follow the rest of the steps when creating trackers. For more information, see Creating Trackers.

Similarly, if a tracker is already created, you can make the tracker available by selecting the Available as template check box on the General tab:

For instance, the Approvals Tracker from the Forking sub-processes from processes (work items) can be made available as template tracker.

To create a derived tracker, do the following:

In our example, the template tracker (Approvals) is from the same project (Workflow Demo), where we create the new derived tracker. But you can create derived trackers from any template tracker in any project to which you have access. A template tracker can exist in one project and a derived tracker in another project.

To let the new tracker inherit the configuration of the  Approvals  tracker ensure that the Inherit template configuration check box is selected. Otherwise, the new tracker gets a snapshot copy of the  Approvals tracker but without inheritance.

You can also optionally mark the new derived tracker to be available as a template, by selecting the Available as template check box. This allows the tracker template to have inheritance hierarchies of unlimited depth.

Instead of individual trackers to be available as templates to be referenced, you can mark an entire project to be available as a template. You can mark an existing project as a template by selecting the Available as template check box on the General tab.

For instance, you can 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:

Click Next to select which components of the template project to copy or inherit:

For each Work or Configuration Item tracker, you can decide individually whether to include this tracker in the new derived project along with the tracker items, or to inherit the template tracker configuration.

For instance, the following is a representation of the Workflow Demo2 project derived from the Workflow Demo project:

Derived trackers can override inherited settings and also add tracker-related settings, that are not present in the template. You can change the value of an inherited setting in the derived tracker to a different value than in the template.

Field dependencies set in the template are used in the derived tracker.

As mentioned in previous sections, some of the derived tracker settings can be overridden. Such settings can be restored and made to follow the configuration in the original template tracker. Project administrators can restore inheritance of all configuration settings.

When you save the derived tracker configuration, Codebeamer compares each setting with the corresponding setting in the template tracker. Only the settings that are overridden and therefore different from the template tracker, are saved in the derived tracker configuration. Identical settings are ignored.

To restore inheritance, you need to edit the derived tracker’s configuration settings to match the template tracker’s configuration settings and save the derived tracker configuration again. Restoring inheritance means the override of the configuration setting in the derived tracker is being reset and the derived tracker resumes following the configuration in the template tracker. 

If the same setting is changed in the template tracker and the derived tracker simultaneously, the setting in the derived tracker takes precedence.

However, in certain situations, an incorrect order of definitions can cause unexpected behavior, for example:

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

While changing a template tracker is technically possible, it could lead to inconsistencies that might even result in masking data in the tracker in baselines. Therefore, changes to a template tracker must be done after thoroughly testing the impact in a test environment before making the change on production.

Refer to the subsequent sections for more information on inheritance based on the configuration type.

Tracker-level permissions are inherited and can be overridden per grantee (role or member field value).

The following is an example of the override in the Workflow Demo project. The Stakeholder role for the Tracker - Subscribe permission has been cleared.

Similarly other permissions can also be overridden.

If the template tracker and the derived tracker exist in different projects, permissions settings for additional roles (set at project level) in the template tracker, are not inherited in the derived tracker. Similarly, additional roles in the project containing the derived tracker are not impacted by inheritance. Only those roles that are common between the template and derived trackers are inherited in the derived tracker. For instance, if the Developer Role is present in both projects, the role will be inherited in the project containing the derived tracker.

If you create a role in the template project that has the same name as a role in the derived project or vice-versa, it does not automatically update the permissions in the derived trackers. This is due to the fact that such an action would override the existing permissions in the derived trackers.

All tracker field settings are inherited and can be overridden individually per configuration setting. Shared fields can be added or removed individually. Adding or removing a status from "Mandatory in Status" is considered as an override of that particular status. Changing the setting of the "All, except" check box results in overriding all status values.

For Fields, you can override inherited settings such as the following:

Once a tracker field has been overridden, if you set the same value for a derived field attribute as is configured in the corresponding template tracker field attribute, the inheritance is restored.

For tracker field permissions, if any access permission is changed in a derived field, it is not inherited from the referenced tracker field. For instance, if the developer role permissions for a tracker field are changed, the permissions will not be inherited from the referenced tracker field.

Similarly, for tracker field permissions, if the access type is changed in a derived field, it is not inherited from the referenced tracker field. For instance, if the Severity field access type is changed in a derived tracker from Single to Same As, any changes in the template tracker will not be inherited by the referenced tracker.

This section applies to “choice” type reference fields with Work or Configuration items configured as a Datasource.

When inheriting the configuration, Codebeamer redirects the configured target trackers to trackers in the same project according to following rules:

If the resulting target tracker does not contain the filter configured in the template no filter is selected after the projection.

Adding and removing configured targets of a reference field or changing the reference filter results in the complete reference target configuration being overridden. This means that changes to the referenced targets of the field in the template will not reflect in the derived tracker. Changes resulting from the reference target projection will not be considered a modification.

Changing the conditions of a reference filter overrides or modifies the filter in the target tracker.

The reference filter is overridden if the filter has been inherited from the template of the target tracker or otherwise modified. The modification applies to all trackers using the same reference filter. Changing the name of a reference filter results in the creation of a new filter and not in overriding the existing filter.

You cannot delete overridden reference filters. Any attempt to delete the filter results in restoring the inheritance from the referenced filter.

For more information on Reference Redirection section see the following section.

In the previous example, the illustration for the inheritance between the Workflow Demo and Workflow Demo 2 projects shows an important feature regarding the inheritance of references between trackers.

The following is an example of an active reference inheritance with redirection.

Assume a tracker AD is derived from tracker A. Also assume that tracker A has a reference X to tracker B (A->B).

Similar to the derived tracker AD, there is a derived tracker BD that exists in the same project as tracker AD. Tracker BD is derived from tracker B that exists in the same project as tracker A.

X had a reference A->B, so the derived tracker AD will have a similar reference AD->B. Because the original reference existed between A->B, the derived trackers will have a similar X reference AD->BD. The derived trackers reference will take precedence and the X reference of AD->BD will overwrite the earlier AD->B reference.

Another example could be the same scenario where AD is derived from tracker A. However, B is not selected on the Select components to copy from project from the template project page. Therefore, BD will not exist in the derived project but the original AD->B reference will exist. For more information on the Select components to copy from project option, see Creating Projects by Using Template Projects.

Consider the earlier Forking sub-processes from processes (work items) example template project:

The Approvals tracker has a field Subject that references the Processes tracker. The Subject field is similar to an X reference in our earlier description. Workflow Demo 2 has an Approvals tracker derived from Workflow Demo ->Approvals, and a Processes tracker derived from Workflow Demo ->Processes. The Subject field in the Approvals tracker in Workflow Demo 2 will be overwritten to refer to the Subject in Workflow Demo 2->Processes.

Reference inheritance with redirection is also applied to other inheritable tracker settings:

This section applies to "choice" type reference fields with a list of configured choice options.

Adding, removing (mark as obsolete), or modifying a referenced choice option field overrides the referenced choice option field. The overridden choice option field does not inherit any changes from the template but will be deleted if it is deleted in the template.

Field level access permissions are inherited and can be overridden at the level of each individual permission setting per field. This means that it is possible to override a setting for an individual grantee and status while maintaining inheritance of permissions for other grantees and statuses.

In inheritance, field level access permissions take precedence over role permissions. In general, field accessibility depends on the role permissions for a field. If a field type is changed in a template or parent tracker, the change will reflect in the field type of the derived tracker. This can affect access to the field in the derived tracker because of a field type change, even if there are no changes in the role.

Adding or removing allowed values or changing the default value for a specific status results in overriding the configuration for that status. Therefore, changes to the allowed and default values in the template are not reflected in the derived tracker for the overridden status.

The list of allowed and default values only shows the values that are valid in the derived tracker even if the template is using other values. Omitting the invalid values is not considered overriding allowed and default values.

Field dependencies are inherited in the derived tracker and can be overridden in the derived tracker. The override applies to all rules and not to individual rules.

The list of static dependencies shows only values that are valid in the derived tracker even if the template is using other values. Omitting the invalid values is not considered overriding dependencies.

Rules for the dynamic reference dependencies refer to trackers. In the derived trackers the targets are redirected according to the rules described in the Reference Fields chapter. Rules that are not valid in the derived tracker are not shown. Redirecting trackers in the rules and omitting invalid rules are not considered overriding dependencies.

Computation fields are inherited from the template tracker and can be overridden.

Dependencies detected for the computation in the template tracker, are inherited by the derived trackers, mapping the trackers in the dependencies, based on the rules defined for the reference fields. Overriding the computation also stops inheritance of the dependencies.

Workflow events such as state transitions, state entry, state exit, and change handlers are inherited from the template tracker. Individual settings of workflow events can be overridden in the derived tracker. Roles configured for workflow events are inherited and can be overridden per role.

Guards can be overridden by changing the conditions defined for the guard. Attempts to delete an overridden guard results in restoring inheritance for that guard.

The same applies to the change filter of Change Handlers and the condition of Actions.

Actions assigned to workflow events are inherited. Action settings can be individually overridden. For actions that work with referred or referring items the reference configuration is rewritten the same way as the configuration of reference fields is rewritten.

Filter conditions and escalation rules are inherited from the template tracker and can be overridden. Overriding a filter stops the propagation of the condition changes from the template. Overriding an escalation rule stops the propagation of all rule settings from the template.

You cannot delete inherited filters and escalation rules defined in the template. Deleting rules results in restoring the inheritance instead. You can reset the override of a filter by deleting the filter in the derived tracker. This resets the filter and the associated escalation rules based on the template tracker.

Similarly, the override of an escalation rule can be reset by deleting the escalation rule.

Recipients (roles, and members) configured to receive "Any notifications" or "Status change notifications" are inherited from the template. Individual users configured as recipients are not inherited into templates.

Notifications can be overridden per recipient configured for a specific event.