Describe the bug
After an administrator changes a user's role (administrator ↔ agent), that user's sidebar keeps showing the inbox list of their previous role. This happens in tabs that are already open, and it persists after a full page reload.
- Administrator → agent: the user still sees every inbox in the sidebar, although they are a member of only some of them. Opening one of the other inboxes shows an empty list. Server-side scoping (
InboxPolicy::Scope, Conversations::PermissionFilterService) works, so this is a stale-UI bug, not an access-control problem.
- Agent → administrator: after a reload the user still sees only their member inboxes instead of all inboxes.
The stale list stays until one of these happens:
- something changes an inbox in the account;
- the Redis cache key expires (72 h);
- the user logs out and back in (logout deletes the IndexedDB stores).
Related: #15549, where open sessions keep the old role after a role change. The page:reload broadcast proposed there would not fix this one. After the reload the inbox list is served from IndexedDB again, because its cache key never changed.
To Reproduce
- Create user U as an agent who is a member of only Inbox A, in an account with several inboxes.
- Log in as U. The sidebar's Channels section shows only Inbox A.
- As an administrator, change U's role to administrator. Use Settings → Agents → Edit, or
PATCH /api/v1/accounts/:account_id/agents/:id with {"role": "administrator"}.
- Reload U's browser tab.
- Actual: Channels still shows only Inbox A.
GET /api/v1/accounts/:account_id/inboxes is not requested on this load; the list comes from IndexedDB.
- Correct: an administrator should see every inbox.
- Log out and back in as U. All inboxes are shown, which is correct.
- As an administrator, change U's role back to agent.
- Reload U's tab.
- Actual: Channels still lists every inbox, although U is only a member of Inbox A. Clicking another inbox shows an empty list.
Expected behavior
After a role change, the user's inbox list should match their new access, at least after a reload and ideally live in already-open tabs.
Root cause
- The dashboard loads inboxes through
CacheEnabledApiClient#getFromCache (app/javascript/dashboard/api/CacheEnabledApiClient.js). It compares GET /api/v1/accounts/:account_id/cache_keys → inbox with the key stored in IndexedDB (cw-store-<account_id>). When they match, it serves the cached list.
- The account's
inbox cache key is only bumped in two places:
- by
AccountCacheRevalidator on Inbox create/update/destroy;
- by
Inbox#add_members / #remove_members, via update_account_cache.
- A role change on
AccountUser does not bump it. invalidate_filtered_unread_count_visibility_update dispatches ACCOUNT_CACHE_INVALIDATED only when filtered unread counts are enabled, and it sends the unchanged cache keys, so clients don't refetch either.
- The server's inbox list does depend on the role:
InboxPolicy::Scope#resolve → user.assigned_inboxes, which returns all inboxes for administrators and member inboxes for agents. So the cached copy is wrong after the change.
Suggested fix
Bump the inbox cache key when the role changes. update_cache_key also dispatches account.cache_invalidated with the new key, so open tabs, including the affected user's, refetch the inbox list:
# app/models/account_user.rb
after_update_commit :invalidate_inbox_cache, if: -> { previous_changes.key?('role') }
def invalidate_inbox_cache
account.update_cache_key('inbox')
end
custom_role_id changes may need the same treatment if custom roles affect inbox visibility.
Workaround:
- Any inbox change refreshes everyone, for example open any inbox → Collaborators → Update without changes.
- Or the affected user logs out and back in.
Environment
Docker (self-hosted v4.18.0). The relevant files are unchanged on develop as of 843385f (2026-10-01).
Cloud Provider
AWS
Platform
Browser
Operating system
macOS
Browser and version
Chrome (Chromium)
Describe the bug
After an administrator changes a user's role (administrator ↔ agent), that user's sidebar keeps showing the inbox list of their previous role. This happens in tabs that are already open, and it persists after a full page reload.
InboxPolicy::Scope,Conversations::PermissionFilterService) works, so this is a stale-UI bug, not an access-control problem.The stale list stays until one of these happens:
Related: #15549, where open sessions keep the old role after a role change. The
page:reloadbroadcast proposed there would not fix this one. After the reload the inbox list is served from IndexedDB again, because its cache key never changed.To Reproduce
PATCH /api/v1/accounts/:account_id/agents/:idwith{"role": "administrator"}.GET /api/v1/accounts/:account_id/inboxesis not requested on this load; the list comes from IndexedDB.Expected behavior
After a role change, the user's inbox list should match their new access, at least after a reload and ideally live in already-open tabs.
Root cause
CacheEnabledApiClient#getFromCache(app/javascript/dashboard/api/CacheEnabledApiClient.js). It comparesGET /api/v1/accounts/:account_id/cache_keys→inboxwith the key stored in IndexedDB (cw-store-<account_id>). When they match, it serves the cached list.inboxcache key is only bumped in two places:AccountCacheRevalidatoron Inbox create/update/destroy;Inbox#add_members/#remove_members, viaupdate_account_cache.AccountUserdoes not bump it.invalidate_filtered_unread_count_visibility_updatedispatchesACCOUNT_CACHE_INVALIDATEDonly when filtered unread counts are enabled, and it sends the unchanged cache keys, so clients don't refetch either.InboxPolicy::Scope#resolve→user.assigned_inboxes, which returns all inboxes for administrators and member inboxes for agents. So the cached copy is wrong after the change.Suggested fix
Bump the inbox cache key when the role changes.
update_cache_keyalso dispatchesaccount.cache_invalidatedwith the new key, so open tabs, including the affected user's, refetch the inbox list:custom_role_idchanges may need the same treatment if custom roles affect inbox visibility.Workaround:
Environment
Docker (self-hosted v4.18.0). The relevant files are unchanged on
developas of 843385f (2026-10-01).Cloud Provider
AWS
Platform
Browser
Operating system
macOS
Browser and version
Chrome (Chromium)