Skip to content

fix(core): don't show no-access page to users who have app access#7769

Merged
davidecavaliere merged 2 commits into
masterfrom
fix/no-access-stale-route
Jun 23, 2026
Merged

fix(core): don't show no-access page to users who have app access#7769
davidecavaliere merged 2 commits into
masterfrom
fix/no-access-stale-route

Conversation

@davidecavaliere

@davidecavaliere davidecavaliere commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Problem

Users who do have app access could still land on the "You do not have any access to any app, contact administrator." page — the same page shown to brand-new users with no access. Global admins could similarly land on the initial-setup page. It was intermittent and survived re-login.

Root cause

  1. A user logs in with no access (e.g. SSO auto-provisioning) → routed to /account-settings/no-access (or a global admin with no apps → /initial-setup).
  2. That route is stored as the last-visited page and restored on the next login.
  3. The user is later granted access.
  4. On the next login the dead-end route is restored, and its view renders purely from the route — it never re-checks that countlyGlobal.apps is now populated.

The app id is present in the URL and the app is fully usable (the sidebar loads, and a direct app link works). Only the landing route was stale.

Fix

Guard both dead-end routes so an authorized member (apps present) is redirected to their default app instead of being shown the page:

  • plugins/plugins account-settings route/account-settings/no-access
  • core onboarding route/initial-setup

This is route-level and precise: it catches the dead-end no matter how it was reached, with no fragile URL string-matching.

🤖 Generated with Claude Code

…e app access

Users who actually have app access could still land on the
"You do not have any access to any app, contact administrator." page
(and global admins could land on the initial-setup page). This happened
when a user first logged in with no access (e.g. SSO auto-provisioning),
was later granted access, and logged in again: the dead-end route had
been stored as the last-visited page and was restored on the next login,
and that view renders purely from the route without re-checking that the
member now has apps.

Guard both dead-end routes so an authorized member is redirected to
their default app instead of being shown the page:
- plugins/plugins account-settings: /account-settings/no-access
- core onboarding: /initial-setup

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@davidecavaliere davidecavaliere force-pushed the fix/no-access-stale-route branch from 5153157 to da1c970 Compare June 22, 2026 14:49
@davidecavaliere davidecavaliere merged commit fcd53d3 into master Jun 23, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants