This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to
Article Number 000385088 for more information about troubleshooting BMC products in containers.
Legacy ID:KA372090
This problem was initially reported as a defect in SW00431892. After a review of the code and confirmation with dev engineering, it has been confirmed that the behaviour is not a defect but, rather, as-designed behaviour in the defined scenario being used for testing and the defect has been resolved with status 'As Designed'.
Please reference this excerpt from pg. 31 of Configuration Guide for reference explaining why the due date is not being reset when the service targets are in the same service target group:
Tracking time by support teams
This feature is useful for internal reporting purposes; you can create internal OLAs
(operational level agreements) to track how long a support team spends on a
request. When a request is reassigned from one group to another, the OLA can
keep track of how long each team worked on the request using the contents of a
field specified in the data source. The goal time is not reset when the request is
reassigned.
The same behaviour is consistent testing the same scenario with v7.1 through the current v7.6.04 releases. Confirming this is as-designed behaviour explains why this has not been determined to be a defect or problem prior to this time. Additional testing in test systems where the development and testing is taking place also confirms this behaviour persists in for future releases of SLM. The QA test plan includes a test case to verify that reset does not take place within SVT groups.
By definition, service target group functionality logic is one of inheritance. Following is an excerpt from pg. 38 of the 7.6.03/7.6.04 Configuration Guide noting this design:
When key criteria for an incident are modified and the incident has a service target
attached, the system searches to see if a service target meeting that criteria already
exists in the same group. If so, the new service target attaches to the incident
request and inherits the data, such as start time, goals, or milestones, from the
original service target. The system re-calculates the due date and time and the
original service target is removed.
When the service target group workflow takes precedence, the goal time will not be reset.
As a sidenote, there is another test case to verify that the Reset and Re-Open should not work together. If the service target has both options defined, it is assumed they are not used concurrently.
Because the behavior is consistent with the design of current workflow, there is a decision and choice between tracking across assignment and using a service target group. Either
1) the service target group functionality is implemented (reference Configuration Manual starting on pg. 38) and the due date is not reset with reassignment to a different group and a single service target is attached to the incident; or
2) the reset functionality is implemented, in which case there will be a separate service target attached for each update between Critical and High with separate measurement records for each time either service target attaches to the incident
An RFE has been submitted for evaluation of design change to have both SVT group and Reset functionality co-functional in a future release of SLM: see SW00432818. As the current behaviour is based on a very mature design model, this RFE will require business impact of current design to be considered.
Related Products:
- BMC Service Level Management