How do i delete the object/entity for a call (maybe even via the zammad rails cli)?
Context
As you can see under “steps to reproduce the behavior” i messed up my http-https-config.
I did provide the sipgate developer console webhook with the zammad http-webhook-uris and set zammad to use https a while after.
This lead to calls that were answered/rejected/aborted to be left as INBOUND CALLs. They are still showing up as inbound calls even after de-activating the sipgate.io-integration, restarting zammad and rebooting the servers.
I can tick the done-box in the call log, which makes them disappear from my side menu, but in the call log they are still listed as ringing
Steps to reproduce the behavior:
In Zammad config -> System -> Base set HTTP type to http
Config the sipgate webhooks with the http-webhook-uris
In Zammad config -> System -> Base set HTTP type to https
You’d need to manually update the entry via rails or so.
The question that raises on my end “Is it really that awful”?
Because Zammad will only show the last 60 current entries, so if you received enough calls, it would be gone. :-X
Any way.
Please be aware that the following is soley on your own risk. We do not support manual fiddling via rails and won’t be able to help you, if something breaks. Create a backup before you continue!
Rails-Way
Cti::Log.pluck(:id)
returns all available CTI-Log entries
Cti::Log.find({ID})
will return the ID you’re querying
if you append above with .destroy will remove unwanted entries.
Note This removes data without any further warnings, double check, this action can’t be undone.
Technically you should also be able to update entries ( .update()), but I didn’t find a good way and currently don’t have time for that. sorry.
Note
Zammad won’t be able to “process DELETE request to elasticsearch[…]”, so indices won’t be updated i think. I suggest not using this in production and stick with Marcel’s solution of waiting for Zammad to drop the call info after the 60th comes in.
