feat: update version 3.5.2 #13
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…oot#8591) Co-authored-by: snyk-bot <[email protected]>
…hatwoot#8509) Co-authored-by: Sivin Varghese <[email protected]>
…hatwoot#8628) Co-authored-by: snyk-bot <[email protected]>
…8625) Co-authored-by: snyk-bot <[email protected]> Co-authored-by: Pranav Raj S <[email protected]>
- Add config for dark mode logo
This enables local decorating of logs when using a new relic. It can be used when you use a log forwarding agent to do additional enrichment on APM logs before forwarding to the new relic.
This PR logs additional information in content_attributes of a message in case it is unsupported. This info can be used by the client to render a fresh UI
- Use fakeTimer for time.spec.js - Use default sort as last_activity_at_desc - Update specs for getAllConversations getter
We observed an issue in production where the external webhook for an API inbox was failing. This, in turn, calls message update to update message status to failed. This causes a loop because rails trigger after_update callbacks even for empty commits. Ref: rails/rails#44500
- This PR adds a feature to auto-trigger handoff events when an Agent bot toggles a conversation status from Pending to Open Co-authored-by: Sojan <[email protected]>
Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
We have been observing JSON parsing errors for responses from GPT. Switching to the gpt-4-1106-preview model along with using response_format has significantly improved the responses from OpenAI, hence making the switch in code. ref: https://openai.com/blog/new-models-and-developer-products-announced-at-devday fixes: #CW-2931
…#8670) The primary cause of this issue is when Chatwoot sends a message to a channel that has either been deleted or is unauthorized. So, we will prompt reauthorization when this error occurs. Fixes https://linear.app/chatwoot/issue/CW-2930/slackwebapierrorsnotinchannel-not-in-channel
`plan` isn't a guaranteed object in stripe `customer.subscription.updated` events. It can be null for cases like `send_invoice` for `past_due` event as seen in the payload shown in sentry error. fixes: https://linear.app/chatwoot/issue/CW-2925/nomethoderror-undefined-method-[]-for-nilnilclass-nomethoderror
Skips audit logs for whatsapp_template sync Fixes: https://linear.app/chatwoot/issue/CW-2641/skip-whatsapp-template-updates-from-audit-logs
Display an unsupported message in UI when handling unsupported messages from channels like facebook, Instagram etc. Co-authored-by: Pranav Raj S <[email protected]> Co-authored-by: Sojan Jose <[email protected]>
…chatwoot#8677) This case occurs for bounce notification emails where the from address is From: "" (Mail Delivery System) . We will be discarding these emails for now. Fixes: https://linear.app/chatwoot/issue/CW-2793/activerecordrecordinvalid-validation-failed-email-invalid-email
The sentinel configuration set in this specification seems to be affecting other specifications. So, let's ensure that the memoised config variable gets unset after execution of the spec.
…hatwoot#8647) Co-authored-by: Muhsin Keloth <[email protected]>
… exceeds the page size. (chatwoot#8723) - The notification count is incorrect when the number of notifications exceeds the page size.
…hatwoot#8730) The Inboxes::FetchImapEmailsJob is designed to fetch the entire email object and check if its message id is already in the database. However, this process is resource-intensive and time-consuming, as fetching the full email object takes a significant amount of time. On average, fetching 100 emails can take approximately 3-4 minutes to complete depending on the IMAP server. Since we are not using server flags to identify which emails have already been fetched (to avoid compatibility issues with flags in different email services), we have to fetch all previously available emails. Currently we fetch all the messages that were created from yesterday. This becomes problematic with services like Gmail, which throttle requests based on bandwidth usage. To address this issue, I have updated the logic as follows: Fetch the sequence IDs of all the mails in the "Inbox" that were created from yesterday. Use the FETCH command to fetch only the message-ids using BODY.PEEK[HEADER.FIELDS (MESSAGE-ID)] with the sequence IDs we got in the previous step. This is a faster operation with lower bandwidth usage, as it only returns the sequence ID and message ID. Check if the message IDs are already present in the database for the selected inbox. If not present, fetch the entire email object using the FETCH command and create the message. If the message ID is already present, ignore it and move on to the next message-id. I have also addressed the issue of duplicate emails appearing in conversations when two fetch email jobs occur simultaneously. I have added a lock for the channel to ensure that the job gracefully exits without waiting for the current job to complete. Fixes chatwoot#7247 Fixes chatwoot#6082 Fixes chatwoot#8314 Co-authored-by: Sojan <[email protected]>
- this ensures that the markdown formatted messages from the Chatwoot dashboard will render consistently in telegram UI for the supported types like bold, italics, links etc
- Fixes the issue in release 3.5.0, which causes SuperAdmin tokens to throw error during API calls Fixes: chatwoot#8719
…oot#8742) - Improve active job error logs for deserialization error Co-authored-by: Sojan <[email protected]>
…t#8745) - Use white-label settings for Chatwoot Help Center Co-authored-by: Sojan <[email protected]>
… gem (chatwoot#8743) - Update the message ID parsing logic to use the mail gem - Update the code to improve readability
…twoot#8744) Consider a scenario where two jobs are concurrently accessing a job with a lock mechanism. If the second job accesses lock_manager.locked? before the first job called lock_manager.lock(lock_key), it would return a false positive. At this point, both jobs can be executed freely. To address this issue, the following change ensures that only the current thread that has set the lock can execute. Otherwise, a LockAcquisitionError will be thrown. Co-authored-by: Sojan Jose <[email protected]> Co-authored-by: Shivam Mishra <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.