Skip to content

Inbox list stays stale after a user's role changes, even after a page reload (inbox cache key not invalidated) #16107

Description

@mishraadityan09

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

  1. Create user U as an agent who is a member of only Inbox A, in an account with several inboxes.
  2. Log in as U. The sidebar's Channels section shows only Inbox A.
  3. 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"}.
  4. 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.
  5. Log out and back in as U. All inboxes are shown, which is correct.
  6. As an administrator, change U's role back to agent.
  7. 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)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugSomething is not working as expected🧄 feature/agent-uiCommon issues in agent dashboard that cannot be attributed to a specific feature

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions