Currently, if Enable email collect box is enabled, and the user starting the chat already has an account with the same email, it will override the current account with {name} from the email name@email.com , this fixes it.
Co-authored-by: Sojan <sojan@pepalo.com>
When looping the conversations in bulk action to assign them to new labels, the existing labels in other conversations were also getting duplicated across all conversations. This PR fixes the issue.
> In the previous implementation, new_labels is appended to the existing labels using the << operator. This operator modifies the original array instead of creating a new one, causing unwanted side effects. More specifically, new_labels is a reference to the original argument array of the method.
Co-authored-by: Sojan <sojan@pepalo.com>
Co-authored-by: Peter Salib <74493166+Peteraymansalib@users.noreply.github.com>
This class inherits from Api::V1::Accounts::BaseController, which already includes EnsureCurrentAccountHelper and also sets up before_action :current_account.
We have display_name and the actual name for an agent. display_name is used in all public facing parts. The https://github.com/chatwoot/chatwoot/pull/7232/files PR missed this and used actual name instead.
This PR fixes it.
* logging the messages id for message validation exception
* Update the processed_message_content validation over length
* codeclimate
* specs failing for contacts
- Adds support for superscript when rendering article markdown
- Chatwoot Markdown Render to render markdown everywhere
Co-authored-by: Sojan <sojan@pepalo.com>
* fix: calculation for resolution count
* test: resolution count bug fix
- ensure enqueued jobs are run
- fix the dates check, conversations resolved today should show up in today
* feat: ensure conversations are resolved
* test: do not count extra events if the conversation is not resolved currently
* fix: typo
Update the cache headers for cache_keys to max-age=10, private, stale-while-revalidate=300
1. The cache will be fresh for 10 seconds (max-age=10). During this time, the browser will use the cached version without checking with the server.
2. After the initial 10 seconds, the browser can continue to serve the stale cache for up to 5 minutes (stale-while-revalidate=300). During this period, it will also try to revalidate and update the cache in the background.
3. After 310 seconds in total (10 seconds fresh, 300 seconds stale), if the browser has not been able to revalidate the cache, it will attempt to fetch the fresh resource directly from the server for subsequent requests, causing potential latency equivalent to a network request.
This means that the data will be directly revalidated only every 5 mins. Other times, it will stay fresh for 10 seconds and revalidate in the background. In most cases, we won't have to rely on a cache validation check because there is a WebSocket event for revalidation, so we know if something changes.
Right now the stale-while-revalidate is 5 minutes, we can then move it to 15 minutes.
> The stale-while-revalidate header is not supported in Safari, for Safari the cache keys will only stay in memory for 10 seconds before being marked stale
