Patch Release CX4.9.3

CX4.9.3

Introduces the Proxy API for formData transmission to the Form API, enhances security and authentication for file engine APIs using APISIX, implements IP-based rate limiting for the Message Send API to optimize traffic control, and integrates RSA SecureID support for 2-FA in CX Apps to reinforce security measures.

Resolved various issues in the Email connector, supervisor login, and agent reply.

Upgrade Guide CX4.9.2 to CX4.9.3

Previously, Web Published Forms transmitted formData to the Conversation Manager API. This has now been replaced with a proxy API that forwards the payload to the Form API's /activity/formData endpoint.

The proxy handles authentication with Keycloak, using service credentials to generate a token, and attaches the received token as a Bearer token.

File Engine APIs are now secured/authenticated at the ingress level using an Auth Plugin (APISIX) and integrated with Keycloak for authentication and token validation.

Implements IP-based rate limiting in APISIX for customer messages. This helps mitigate the risk of Denial-of-Service (DoS) attacks by controlling excessive requests from a single IP address.

Enables two-factor authentication with RSA SecureID for CX users (Agent, Supervisor, or Admin) to ensure authenticity more securely at the login screen on CX user apps (Agent Desk, Unified Admin).

Some of the APIs related to user login are excluded from authentication

Allows the agent to visually identify the change in color of the Agent SLA timer and chat icon in the left sidebar to RED upon the expiry of the Agent SLA threshold with this new action.

Implemented enhancements to the logout process by assigning default reason codes, ensuring supervisors' team logouts include a reason, and capturing logout reasons for API authentication failures (401), improving clarity and tracking.

In cases where the Agent’s state or any of the Agent’s MRD state is other than NOT_READY or if the Agent has any ACTIVE or RESERVED task, then the request to logout the agent will not be processed. It can only logout if either above conditions are false or the reasonCode in the agent state request is FORCED_LOGOUT.

Issue: In Auto-Accept mode, event processing occurs unexpectedly fast, leading to abnormalities such as session unavailability.

Resolution: To resolve this, a configurable delay has been introduced, applicable only when the Auto-Accept feature is enabled. A new configuration parameter, AUTO_ANSWER_DELAY, has been added to the agent desk with a default value of 5000 milliseconds, ensuring controlled event processing and improved stability.

Issue: The default file upload size was previously limited to 1MB.

Resolution: Increased the default upload limit in APISIX to 5MB. Refer to this document for detailed instructions on further increasing the limit at the APISIX Ingress level.

Issue: The supervisor was previously unable to log in to the Unified Admin application due to the application's reliance on the FQDN for KeyCloak configuration.

Resolution: A new environment variable has been introduced in the application's (Unified Admin) backend, enabling the use of the service name (svc) instead of the FQDN for Keycloak configuration, ensuring internal API requests.

Issue: Previously, when the primary agent transitioned to the WRAP_UP state and left the conversation, the secondary agent was also unsubscribed. However, the channel session remained active, resulting in the conversation not being closed properly, even though no agent was present.

Resolution: This has been addressed by updating the controller training logic. Now, if all PRIMARY agents are in WRAP_UP state (and the transition is not due to a transfer), the system will automatically end the CHANNEL_SESSION, ensuring the conversation is correctly closed.

Issue: The full detail view of email threads does not display time stamps for individual emails. This omission makes it challenging to track the chronological order and timing of conversations, potentially disrupting communication flow and context.

Resolution: A new field for timestamp is added between the “To” and “From” email addresses, which will show the timestamp of the email in Thread View.

Issue: When replying to an email or initiating an outbound email during a conversation, if an attachment contains errors, the system displays a warning but proceeds to send the email with valid files, skipping the invalid ones.

Resolution: The issue has been resolved. If any attachment encounters an error, the system will display the error while keeping the email composer open. The email will not be sent until all attachment issues are resolved.

Issue: Previously, when agents viewed customer emails in the Agent Desk interface, the email content appeared misaligned or distorted, affecting readability and usability. This issue impacts the ability to process customer messages.

Resolution: The issue has been resolved by introducing support for inline images, ensuring that email content is displayed correctly, allowing customers to view emails without distortion.

Issue: Previously, when sending emails with a logo or image in the signature, recipients could not view the image as expected.

Resolution: This issue has been resolved by implementing support for inline images.

Issue: For YouTube, LinkedIn, and Email channels, the message composer was disabled by default. However, after a conversation was paused and then resumed, a plain text message from the bot was received with "Edit" and "Reply" options. When the agent clicked either option, the plain text message from the bot appeared in the composer. Even though the agent was unable to send the direct message for these channels, the text was appearing in the disabled composer.

Resolution: To avoid confusion on these three channels, the "Edit" and "Reply" options are now hidden on plain text messages sent from the bot during a paused/resumed conversation.

Issue: In the Customer widget, while uploading a large-sized file, it throws an error and does not allow it even though the file size is valid according to File Engine.

Resolution: It is because of some pre-defined/fixed restrictions on file size in the customer widget. It’s removed now, and the file size limit is now being used from the file engine.

Issue: In the Customer widget, even if we send a larger file or an invalid file format, it always throws a consistent error message of “fileName is not valid …”.

Resolution: It is fixed by handling the errors based on the file engine response instead of making it pre-defined in the customer widget.