Closed pzbdkp closed 8 months ago
Please try if you reproduce on latest stable release
Please try if you reproduce on latest stable release
We've already did an upgrade a month ago from 10.0.x to 10.0.10 to solve this issue and it is still present. That is why I've created a bugreport for this issue. What extra log or information is needed to investigate this issue?
Ok, we've updated GLPI to 10.0.12 on 5th of februari.
We've noticed today this problem is still present in the latest version.
TTR on impacted ticket:
Information in tab historical:
Notice the difference for TTR between tab historical and actual TTR on ticket. Last change was friday evening, nobody worked this weekend and mondaymorning TTR is changed without a trace...
Do we need to provide some logfiles or what information can assist further to investigate this issue?
The time to resolve is recomputed when the status change from pending
to something else, or if a rule changes the SLA value.
Thanks for the reply.
And where can I find the recomputing value for the TTR at status change? Because sometimes TTR changes 1 month into the future and sometimes it is 1 week into the future.
SLA rules are disabled and shouldn't be taken into account.
And where can I find the recomputing value for the TTR at status change? Because sometimes TTR changes 1 month into the future and sometimes it is 1 week into the future.
SLA rules are disabled and shouldn't be taken into account.
Recomputation is done here: https://github.com/glpi-project/glpi/blob/fd2f456c3ba6bed9ca1dd7cf707205128f81db9a/src/CommonITILObject.php#L2352-L2448
Thanks for this.
Is there a reason that a "$delay_time" is added to the TTR?
We want to use the TTR to set a specific date/time and then we need to pick-up that ticket again when TTR is almost due or past due date/time. At this moment we are losing control over those tickets to do the correct follow-up.
Is there a way in the settings to control this recomputation?
Is there a way in the settings to control this recomputation?
No, there is no setting related to this. We consider that this is a normal behaviour. The "waiting" status is made to indicate that you cannot process the ticket because your are waiting for a missing information. If you want your TTR to not be altered, you must not use this state.
I close this ticket as it is not a bug.
This issue has been closed as we only track bugs here.
You can open a topic to discuss with community about this enhancement on suggestion website. You can also contact GLPI editor team directly if you are willing to sponsor this feature.
Ok thanks for the clarification. I understand that this isn't a bug and a suggestion.
I want to make a bug out of it because why is this recomputed value not logged in the historical data of a ticket? Then everyone can see when and why the TTR is changed?
Indeed, lack of history when a manually set TTR is updated can be considered as a bug. We should probably add a log entry of HISTORY_LOG_SIMPLE_MESSAGE
type, with a messages like TTR has been incremented by the waiting time ($time1 -> $time2)
.
Thanks! Also nice to have is what exact event that has been triggered to increment the TTR.
Code of Conduct
Is there an existing issue for this?
Version
10.0.10
Bug description
We noticed that the Time to Resolve (TTR) field on a ticket automatically changes after x time to a future date/timestamp then the date/timestamp that was set by an IT agent.
If we check the historical log on that ticket then there is no indication why this change of the Time to Resolve (TTR) field on a ticket occured.
Is this behaviour familiar to someone and how can this be mitigated?
Here some screenshots to show the issue. Time to Resolve (TTR) field of the impacted ticket:
Historical with no log that the Time to Resolve (TTR) has changed to a future date/timestamp:
Relevant log output
Page URL
No response
Steps To reproduce
It is not after some steps. It just happens on some of our tickets after x time.
Your GLPI setup information
Information about system installation and configuration
Server
GLPI constants
Libraries
LDAP directories
SQL replicas
Notifications
Plugins list
Locales overrides
Anything else?
No response