there are a lot of processes that can cause this. Without further information it is impossible to tell. If you select a ticket, you can have a look at the ticket history (usually in the miscellaneous menu). This should give you a hint about what is going on.
Actually, if there’s no entry in the history, I would guess, that it is either a database problem (the values are read from there), or some process is not correctly producing a history entry. Both of which would be unwanted.
I am right, that you are using docker, are you? Is this already 10.0.3, and did this behaviour start to occur with this patch? The docker version is still under more development, so I would not completely exclude any regressions, here.
From the two pictures you sent I infer, that this happened not only once. If it is chowing up at a certain rate, you could do the following, to get more clues:
Start a shell in the docker-db-container: docker exec -it otobo_db_1 bash
Open up the database with either the root or otobo user and password, e.g.: mysql -u otobo -p otobo #(You can get the otobo password and db details from Kernel/Config.pm within the otobo-container, if you don’t know.)
Get all ticket parameters for one ticket, from your second picture, e.g.: select * from ticket where tn=2020092402000022
Logout, wait for the thing to happen again, repeat, and compare, if you see any changes.
Hopefully this way we get more information. (Ah, have a look, whether other processes changed something in the history again, when doing this, of course.)
ok, I’m pretty sure that is a bug, now. A minor one, though. Could you please go to the SysConfig, disable Daemon::SchedulerCronTaskManager::Task###RebuildEscalationIndex and see, if it continues, or not? We included some extra functionality from another module there, and I guess there is some check missing, whether things actually changed in the ticket, before „the changes“ are written. This should not break anything, but it is erroneous behaviour anyways. We are a little busy at the moment, but if my guess is correct, I will try to find someone to have a look at it this week.
Best regards, Sven
This reply was modified 2 years, 8 months ago by Sven Oesterling.
just to let you know, I opened an issue https://github.com/RotherOSS/otobo/issues/490 – if you are aware of any settings you made regarding the escalation index (I’m especially thinking about the escalation suspend functionality), please let us know. Else I’m confident, that we will find it anyhow.
just for your information: The error came from the escalation index rebuild, which previously was just used when the package was installed. As you don’t use the escalation suspend functionality, disabling this task effectively solved the problem for you (though really nothing much happened anyways). For 10.0.4 we now check whether the rebuild is needed, so it should not occur anymore even with the task enabled.
Our website uses cookies. Cookies are tiny text files which are saved in your web browser or by your web browser on your device when you access websites. They contain a characteristic character sequence allowing to clearly identify your browser upon your next visit to the website.
You can prevent the setting of cookies at any time by making the appropriate setting in your internet browser. Cookies that have already been set can be deleted manually or automatically at any time. This is possible in all common internet browsers. If the setting of cookies is deactivated in the browser, not all functions of the website may be fully usable.
We deliberately use very little cookies.
Detailed information can be found in section 4 of our Privacy Policy.
Necessary cookies
Essential Cookies are necessary to deliver this website and some of its features correctly.
For this reason, we do not provide any opportunity here to disable them.
Notwithstanding this, you can deactivate all Cookies in your Browser Settings at any time. Please be aware, however, that this might have an impact on the functionality of this website.
More information about the cookies to be set and how long they will be stored can be found in section 4 of our Privacy Poliy: Privacy Policy.
Google Analytics' Cookies
When you visit this website, Google Analytics sets cookies on your system. This will help us analyse how you use our website ans tailor it to the needs of our visitors. Your IP address will be automatically anonymised (IP anonymisation and deactivation of your User ID). Therefore, we cannot trace which data a certain user is accessing. The data are not saved together with any other personal user data.
You can deactivate tracking in your browser if you do not want us to be able to track your visit on our website.
Privacy Policy
Detailed information on the usage of cookies as well as our Privacy Policy can be found here: