Release Notes
4.13 Release Notes
Ameyo Contact Center - Patch Release Notes - Version 4.13.37
8 min
release details release date 2025 09 04 short description this release provides a fix for configuring two factor authentication (2fa) via email otp on php 8 x setups and includes fixes for dr server license generation, ha service stability, agent state management, and ui character length restrictions highlights / summary 2fa email otp fix resolved compatibility issues preventing configuration and use of 2fa via email otp on php 8 x dr license generation fixed hardware license generation failures on dr servers using postgresql with custom ports ha stability corrected handling of appserverui service entry in high availability configurations to prevent appserver stops agent state/ui fixes addressed issues with rule engine event data, user id character limits, supervisor campaign assignments, and webrtc status synchronization component versions component build url ameyo server ameyo server 4 13 596 20250903 r 220368 linux gtk x86 64 rpm ameyo djinn ameyo djinn 100 0 413 20250814 r 215753 x86 64 rpm note only components with significant changes are listed other releases has no change and are same delivered in last patch cycle feature enhancements unable to configure two factor authentication via email otp fix (sl 17350) the existing package, originally built for php 7 4, failed on php 8 x environments, preventing the configuration of two factor authentication (2fa) using email otp the implementation has been updated to support php 8 x, ensuring seamless 2fa configuration the flow now functions end to end otps are delivered successfully, ssl validation passes, and the login ui correctly displays the otp input field tech tasks dr drill for ameyo (sl 17397) resolved an issue where hardware license generation failed on disaster recovery (dr) servers running postgresql on a custom port the updated build ensures that the ameyoctl gethardwaredata command executes successfully and generates the required system signature file as expected appserver service stopping in ha mode (sl 17390) fixed an issue in high availability (ha) mode where the appserverui service entry in serviceconf csv was not handled properly when this entry was manually added or removed during upgrades, it caused the appserver to stop or behave inconsistently the latest build ensures stable appserver operation in ha mode without requiring any manual edits to serviceconf csv bugs fixes missing process information in context data (ga 14455) resolved an issue where certain events sent to the rule engine did not include the process id within jobcontext this omission caused process based rules to misfire when a campaign and process were selected during rule configuration the fix ensures all events now consistently include the process id, enabling accurate and reliable rule execution this issue has been resolved in the latest app server build configurable database timeout for flagged stats (ga 15240) introduced support for configuring the flagged stats database timeout through the reload properties api this enhancement allows administrators to adjust timeout values dynamically without restarting the application server, reducing downtime and improving operational flexibility inclusion of lead management history table in clean and drop function (ga 15239) in earlier builds, cleanup operations logged errors related to the lead management history table, which was omitted from the drop table list this prevented recreation of the table during maintenance the table has now been correctly added to the drop function, ensuring clean database resets and error free reinitialization webrtc single session status not syncing with toolbar (sl 17326) fixed an issue where, upon login with webrtc single session enabled, the single session pop up correctly showed an active connection (green), but the toolbar webrtc indicator remained red until a manual reload or duplicate login occurred the synchronization logic has been corrected the toolbar now updates its webrtc status instantly and accurately, without requiring a refresh character length restriction for userid (ga 14912, sl 17019) previously, there was no limit on the character length for the userid field during user creation, allowing excessively long values (for example, 15,000 characters) since the maximum supported get url length is 2048 characters, certain api calls (such as delete user) failed when userid was too long a new validation has been added userid values longer than 500 characters are now rejected with an appropriate error message to ensure system stability supervisor manage section issue with large campaign assignments (ga 14787) resolved a problem where supervisors assigned to large numbers of campaigns (for example, 300 or more) encountered errors due to excessively long query strings exceeding the supported url length the system now fetches assigned campaigns directly from the backend, eliminating dependency on lengthy request parameters and ensuring smooth page loading for supervisor management dtls exchange displayed as pending after successful connection (sl 17360) agents were intermittently shown as being in a “pending” dtls exchange state, even though the webrtc connection had already been established network logs (via chrome //webrtc internals ) confirmed successful dtls handshakes, while the toolbar ui failed to reflect the connected state the fix updates the toolbar logic to display the accurate dtls connection status, preventing erroneous “pending” indications security and performance updates no specific security updates noted in this patch version itself limitations / known issues no new limitations identified in this patch browser and platform compatibility supported browsers chrome version 139 0 7258 128 (official build) (arm64) mobile apps no updates in this patch contact / support information for issues or queries, please contact ameyo support via the support portal or designated email channels
🤔
Have a question?
Our knowledgeable support team and an awesome community will get you an answer in a flash.
To ask a question or participate in discussions, you'll need to authenticate first.