Since we download the GeoIP database during worker/server initialization, there is a high chance of spamming the server with too many requests for downloads, especially if the number of web and worker nodes is high. This PR provides the ability to specify a custom URL for the GeoLite database download, configurable via an environment variable. This helps in distributing the load and avoiding server overload during the initialization process
* feat: start sitemap
* feat: add base url and last mod to sitemap
* fix: typo
* test: sitemap generation
* test: add draft articles
* fix: escape dots in regex matching
* feat: perpend protocol to the url
* feat: use ChatwootApp.help_center_root
* feat: don't parse the URL
* fix: function declaration
* fix: downcase email when finding
* feat: add `from_email` class
* refactor: use `from_email`
* feat: add rule to disallow find_by email directly
* chore: remove redundant test
Since the previous imlpmentation didn't do a case-insentive search, a new user would be created, and the error would be raised at the DB layer. With the new changes, this test case is redundant
* refactor: use from_email
This PR addresses several items listed in our rubocop_todo by implementing the necessary corrections and enhancements. As a result, we are now able to remove the rubocop_todo file entirely, streamlining our codebase and ensuring adherence to our coding standards.
fixes: https://linear.app/chatwoot/issue/CW-1806/chore-rubocop-audit
- Reorganizing installation config settings to move more configurations into UI from environment variables
- Changes to installation config to support premium plans in the enterprise edition
- Fixes the broken premium indicator in account/show and accounts/edit page
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#7247Fixes#6082Fixes#8314
Co-authored-by: Sojan <sojan@pepalo.com>
- Revamp the super admin design
- Introduce a new settings page for support and billing settings
- Move the access tokens into users, agent bots and platform app show pages
Co-authored-by: Sojan <sojan@pepalo.com>
Co-authored-by: Pranav Raj S <pranav@chatwoot.com>
Muhsin Keloth