### Summary
- Converts conversation auto-resolution duration from days to minutes
for more
granular control
- Updates validation to allow values from 10 minutes (minimum) to 999
days (maximum)
- Implements smart messaging to show appropriate time units in activity
messages
### Changes
- Created migration to convert existing durations from days to minutes
(x1440)
- Updated conversation resolver to use minutes instead of days
- Added dynamic translation key selection based on duration value
- Updated related specs and documentation
- Added support for displaying durations in days, hours, or minutes
based on value
### Test plan
- Verify account validation accepts new minute-based ranges
- Confirm existing account settings are correctly migrated
- Test auto-resolution works properly with minute values
- Ensure proper time unit display in activity messages
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
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
* Chore: Feature lock email settings in UI
The email settings under account settings needed to be
feature locked in a way different from teh current way for it
to be enabled for accounts in a self hosted scenario.
Some refactorings were also done along with this change.
1. There was a feature flag defined in code in account model called
domain_emails_enabled was used to check if the inbound emails was
enabled for the account. But there was already a feature flag called
"inbound_emails" defined in features.yml. So changed to use this to
check if inbound emails are enabled for an account.
2. Renamed and re-purposed existing `domain_emails_enabled` to
`custom_email_domain_enabled` to use for feature toggling the UI
for email settings.
3. To enable & disable multiple features using the featurable concern
we were passing an array of values. Changed this to accept a comma
separated set of values.
* Chore: Feature lock email settings in UI
Fixed the specs for accounts controller & removed
unneccessary code from Account seetings component in UI
* Chore: Convert newlines to <br>s
Removed the layout used while sending replies in
conversation continuity.
Converted the newlines in the messages to <br/> tags
for the correct HTML rendering.
* Chore: Bug fix in reply email domain
Renamed the function custom_email_domain_enabled to
inbound_email_enabled.
Fixed bug on setting reply emails's domain.
* Chore: Enable Users to create multiple accounts
Addresses: #402
- migrations to split roles and other attributes from users table
- make changes in code to accommodate this change
Co-authored-by: Pranav Raj Sreepuram <pranavrajs@gmail.com>
Introduce new environment variable that lets you control account signups
ENABLE_ACCOUNT_SIGNUP :( true | false | api_only )
Fixes: #406
Co-authored-by: Pranav Raj S <pranavrajs@gmail.com>
