SanitizeDuplicateViews
 |
Corrections related to reference filters and tracker views are strongly connected, and each correction relies on inconsistencies being fixed by previous corrections.
Before using this correction, it is important to use these corrections in the following order:
1. RemoveInvalidReferenceFilters
2. ReferenceFilterUnifier
For additional information, see Corrections for Reference Filters and Tracker Views.
|
 |
For a general, step-by-step guide on using the corrector module, see Using the Data Inconsistency Corrector Module.
|
Description
This correction detects and deletes duplicated and redundant tracker views.
Conditional filters that are applied to reference filters are called tracker views. For example, using a tracker view, a reference filter can be configured to contain only items in a specific group, not in a specific group, assigned to a specific person, not assigned to a specific person, and so on. Because reference filters are applied to fields, and those fields are in items that belong to trackers, a tracker view applied to a reference filter is stored as part of that tracker.
Errors may sometimes cause tracker views to be duplicated or stored in the database even when they are not used, that is, when they are not applied to any reference filter but are still stored in the tracker. This can lead to problems with saving trackers.
This correction detects duplicated tracker views based on the names of the tracker views. For example, two tracker views with the same name but different configurations are considered duplicates.
Specifically, this correction handles the following issues:
• Unused and improperly deleted tracker views. In this case, the tracker view is not in use, that is, it is not applied to a reference filter. The tracker view is also marked as deleted, but is not physically deleted from the database.
These tracker views are physically deleted.
• Duplicated tracker views with identical configurations. In this case, the detected tracker views are duplicated and identical, that is, their names and configurations are the same. Some or all of these tracker views may also be in use.
Any unused tracker views are physically deleted.
Used and duplicated tracker views are deleted, keeping only one. The kept tracker view is the tracker view with the lowest view_id. Any deleted tracker views that were in use are replaced by the kept tracker view.
• Duplicated tracker views with different configurations. In this case, the names of the trackers views are the same, but their configurations are not the same.
The tracker view with the lowest view_id is unchanged. The other tracker views are renamed. The new name is the name of the tracker view with the lowest view_id, then an underscore (_), then an integer starting at 2.
For example, if the tracker view with the lowest view_id is named my_tracker_view, then the other trackers views are renamed to my_tracker_view_2, my_tracker_view_3, my_tracker_view_4, and so on.
Report Table
The report table for the SanitizeDuplicateViews correction is named duplicate_view_report_table. It contains the following information:
|
Column
|
Description
|
|---|---|
|
id
|
The ID number for the detected issue.
Detected issues are numbered, starting at 1.
|
|
project_id
|
The ID of the project that contains the tracker where the issue was detected.
|
|
project_name
|
The name of the project that contains the tracker where the issue was detected.
|
|
tracker_id
|
The ID of the tracker where the issue was detected.
|
|
tracker_name
|
The name of the tracker where the issue was detected.
|
|
view_id
|
The ID of the tracker view.
|
|
view_name
|
The name of the tracker view.
|
|
view_description
|
The configuration of the tracker view, in JSON format.
|
|
configuration_for_redirect
|
This column is used when the value under marked_for is KEEP_WITH_REDIRECT. It shows the view_id values for the duplicate tracker views.
|
|
marked_for
|
Shows the actions to be performed when clicking Restore.
The following values are possible:
• DELETE—In case of unused tracker views. This tracker view is to be deleted.
• KEEP_WITH_REDIRECT—In case of a used tracker view that has duplicates. This tracker view is to be kept and unchanged.
• REDIRECT_DELETE—In case of a used tracker view that has duplicates with identical configurations. This tracker view is considered one of the duplicates. It is to be deleted and replaced by the kept tracker view, where this value is KEEP_WITH_REDIRECT.
• RENAME—In case of a used tracker view that has duplicates with different configurations. This tracker view is considered one of the duplicates. This tracker view is to be kept but renamed to match the tracker view where this value is KEEP_WITH_REDIRECT, and suffixed with an integer, starting at 2.
For example, if the kept tracker view is named my_tracker_view, these trackers views are renamed to my_tracker_view_2, my_tracker_view_3, my_tracker_view_4, and so on.
|
|
used_as_guard_on_state_transition
|
Boolean value, that is, true or false. 1 means true. 0 means false. True if this tracker view is used as a guard on a state transition.
|
|
used_as_filter_on_field
|
Boolean value, that is, true or false. 1 means true. 0 means false. True if this tracker view is used as a conditional filter on a reference filter.
|
|
used_as_condition_on_workflow_action
|
Boolean value, that is, true or false. 1 means true. 0 means false. True if this tracker view is used as a condition on a workflow action.
|
|
flag
|
The flagged status of the issue, which can be 0 or 1. Clicking Restore corrects issues with a flagged status of 1.
For more information, see the Flagging and Processing Inconsistencies page on the Codebeamer Help Center.
|
|
processed
|
The processed status of the issue, which can be 0 or 1.
For more information, see the Flagging and Processing Inconsistencies page on the Codebeamer Help Center.
|