Release 5.14.12
A small release, entirely about data you can trust: in Clients, a filtered list behaves exactly like the unfiltered one — channels in the row, the right recipients for a broadcast; in operator statistics, the first-reaction column finally measures what its name promises, and operator connection time gets a column of its own; and tickets with a time-in-status auto-close rule no longer stay in that status forever.
Clients
Fixed
- A client's channels are visible again in a filtered list. As soon as you added any condition in the new filters (appeal type, a client field, and so on), the expanded row said "No channels", the channel count disappeared from the expand button, and you could not jump into a dialog from the filtered list. The same client without a filter had their channels in place. A filtered list now shows channels, their count, and the link to the dialog just like the regular one.
- A broadcast to clients selected in a filtered list reaches their contacts again. Because the filtered rows carried no contacts, the broadcast was addressed to the wrong recipients — it could go to the wrong people or to nobody at all. Recipients are now the same as when you select clients without a filter, and the warning about clients with no contact in the bot works again. We recommend reviewing the results of broadcasts previously sent from a filtered client list.
- Exporting a filtered list fills in "Registered contact" and the last interaction date. With an active filter these columns used to come out empty in the export, while the export without a filter had them filled.
Statistics
Fixed
- The "Average first reaction time (s)" column on the Operators tab now measures the time to the operator's first reply. Until now it averaged a different value — the time until the operator joined the dialog. Where requests arrive through auto-distribution or a queue, that time is exactly zero, so the column showed dashes ("—") for most operators even when they were replying to clients within a couple of minutes. The column now counts the time from the operator joining to their first message, exactly as the metrics reference describes it. Why it matters: this is the column used for the "first response after taking the chat" SLA, and on auto-distribution it was unusable for that.
Changed
- Connection time has not disappeared — it now has its own column, "Average operator connection time (s)". It is the same figure you used to see in the first-reaction column, calculated the same way. The Appeals tab already splits these two metrics apart, so both tabs now count them consistently.
Tickets
Fixed
- A ticket no longer gets stuck in a status it was supposed to close from automatically. If a status has a time-based transition configured (for example, "Completed" → "Closed" after 12 hours), the ticket could stay there indefinitely — until somebody changed the status by hand again. There were several causes: an operator switching statuses quickly (two or three switches within a few seconds) cancelled the countdown that had just been armed; occasionally the countdown could not be armed because of a temporary failure; and once the countdown was lost, nothing restored it. The system now re-checks the ticket's current status before cancelling a countdown, retries after a temporary failure, and every 10 minutes finds tickets with a lost countdown in the background and arms it again.
- What this means in practice. Tickets that are already stuck will close on their own over time — each of them runs its auto-close scenario once and sends the related notifications to the assignee and watchers. Tickets whose countdown has already fired are not processed a second time. If auto-close is simply not configured for a bot or a status, it will not appear by itself — the time-in-status transition rule still has to be set up.
Stability and internal improvements
- Diagnostics for time-in-status transitions were extended: the support team can now see why a particular ticket did not move to the next status without direct database access.