EDM-2730: Redirect to valid page after switching organization

[celdrake]

When users switch organization while logged in and while viewing a resource details page, after the switch they don't have access to the same resource as it belongs to the previous organization.

Now we change the page to either the parent page (eg. view repository --> repository list), or Overview as a fallback.

switch-org-details.mp4

Summary by CodeRabbit

• Bug Fixes
  • Organization switching now uses client-side redirects instead of a full reload, preserving user context and mapping detail/edit pages to their appropriate list/overview routes so users end up on the correct overview after switching.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Replaced full-page reload on organization switch with a client-side redirect in PageNavigation. Added a list of primary routes and a helper that maps detail/edit paths to corresponding list/overview paths, using location from app context to compute the redirect and preserve user context.

Changes

Cohort / File(s)	Summary
Organization switch & redirect logic libs/ui-components/src/components/common/PageNavigation.tsx	Added useAppContext import and listRoutes constant; implemented getRedirectPathAfterOrgSwitch to map detail/edit routes to list/overview routes with a root fallback; replaced window reload with client-side navigation using router.useLocation; updated OrganizationSelector onClose flow to navigate to the computed path.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

• Verify getRedirectPathAfterOrgSwitch covers edge cases (nested/detail/edit URLs and query params).
• Confirm useAppContext().router.useLocation and navigation call are valid in this component and preserve history/state as intended.
• Ensure listRoutes includes all relevant app sections to avoid unexpected fallbacks to root.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: redirecting users to a valid page after switching organizations, which aligns with the changeset's primary objective.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee3ebfc and 8a117f8.

📒 Files selected for processing (1)

• libs/ui-components/src/components/common/PageNavigation.tsx (3 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: celdrake
Repo: flightctl/flightctl-ui PR: 363
File: libs/ui-components/src/hooks/useWebSocket.ts:54-58
Timestamp: 2025-10-08T11:21:15.680Z
Learning: In flightctl-ui, when organizations are enabled, all API requests require the org_id parameter and fail with 403 if it's missing. This means users can only reach the Device details page (and its Terminal tab) if they have a valid organization selected, so organizationId will always be defined in that context.

📚 Learning: 2025-04-10T12:22:38.239Z

Learnt from: celdrake
Repo: flightctl/flightctl-ui PR: 266
File: libs/ansible/src/const.ts:20-20
Timestamp: 2025-04-10T12:22:38.239Z
Learning: In the flightctl-ui project, `appRoutes` is defined as a `Record<ROUTE, string>` across multiple applications, requiring all applications to define entries for all route enum values, even when certain routes (like COMMAND_LINE_TOOLS) are only meant to be used in specific applications (like Standalone). For routes not applicable to a particular application, placeholder values are used with explanatory comments.

Applied to files:

• libs/ui-components/src/components/common/PageNavigation.tsx

🧬 Code graph analysis (1)

libs/ui-components/src/components/common/PageNavigation.tsx (3)

libs/ansible/src/const.ts (1)

• appRoutes (3-26)

libs/ui-components/src/hooks/useAppContext.tsx (2)

• appRoutes (18-40)
• useAppContext (123-123)

libs/ui-components/src/hooks/useNavigate.tsx (1)

• useNavigate (49-72)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: integration-tests
• GitHub Check: Build
• GitHub Check: Lint
• GitHub Check: Build ocp plugin

🔇 Additional comments (4)

libs/ui-components/src/components/common/PageNavigation.tsx (4)

24-24: LGTM!

Import is appropriate and aligns with the previous feedback to use routes from AppContext.

---

103-104: LGTM!

Correct usage of useAppContext to access the router and location, following established patterns in the codebase.

---

162-163: LGTM!

Using window.location.href for the organization switch is appropriate here. It ensures a full app re-initialization with the new organization context, which is necessary since all API requests require the org_id parameter. The computed redirect path ensures users land on a valid page after switching.

Based on learnings, when organizations are enabled, all API requests require the org_id parameter.

---

67-98: Verify handling of resource sync details route.

The redirect logic looks solid overall. However, ROUTE.RESOURCE_SYNC_DETAILS exists in appRoutes but is not included in the routeMapping. If a user is viewing a resource sync detail page and switches organization, they'll be redirected to the root page instead of the resource syncs list. Please confirm whether this is intentional.

If resource sync details should redirect to a list page, apply this diff:

 const routeMapping: Array<{ detailRoutes: ROUTE[]; listRoute: ROUTE }> = [
   { detailRoutes: [ROUTE.FLEET_DETAILS, ROUTE.FLEET_EDIT], listRoute: ROUTE.FLEETS },
   { detailRoutes: [ROUTE.DEVICE_DETAILS, ROUTE.DEVICE_EDIT], listRoute: ROUTE.DEVICES },
   { detailRoutes: [ROUTE.REPO_DETAILS, ROUTE.REPO_EDIT], listRoute: ROUTE.REPOSITORIES },
   { detailRoutes: [ROUTE.ENROLLMENT_REQUEST_DETAILS], listRoute: ROUTE.ENROLLMENT_REQUESTS },
   { detailRoutes: [ROUTE.AUTH_PROVIDER_DETAILS, ROUTE.AUTH_PROVIDER_EDIT], listRoute: ROUTE.AUTH_PROVIDERS },
+  { detailRoutes: [ROUTE.RESOURCE_SYNC_DETAILS], listRoute: ROUTE.RESOURCE_SYNCS },
 ];

Note: You may also need to verify that ROUTE.RESOURCE_SYNCS exists as a list route constant and add it to listRoutes if applicable.

Run the following script to check the current route definitions:

#!/bin/bash
# Description: Check if ROUTE.RESOURCE_SYNCS exists and how resource sync routes are defined

# Search for RESOURCE_SYNC route definitions
ast-grep --pattern 'RESOURCE_SYNC$$$'

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

libs/ui-components/src/components/common/PageNavigation.tsx (2)

67-84: Validate redirect heuristics and reduce duplication of route strings

The helper is clear and solves the “detail → parent list” case, but a few points are worth double‑checking:

• It hard‑codes path segments (/edge, /devicemanagement, /admin, /overview, authproviders) instead of using ROUTE/appRoutes, so future route/base‑path changes can drift from this logic.
• Non‑detail URLs like /edge/devices or /admin/authproviders will fall through to '/overview'; switching org from those list pages will jump the user away instead of keeping them on the same list. Please confirm this is intentional for the UX you want.
• The regexes won’t match if routing ever introduces trailing slashes or slightly different segment names (e.g. device-management vs devicemanagement), so it’s worth verifying them against the current appRoutes config.

I’d recommend:

• Basing the returned paths on ROUTE/appRoutes (e.g. mapping the captured entity segment to a route constant) to keep a single source of truth.
• Adding small unit tests for getRedirectPathAfterOrgSwitch with representative paths (device details incl. subroutes, admin details, list pages, and unknown paths) so regressions are caught early.

---

24-24: Reconsider full-page navigation here; prefer router navigation and route constants if possible

Functionally this works, but a couple of aspects could be improved:

• Using window.location.href = targetPath triggers a full reload of the SPA. If you don’t rely on a hard reload to pick up new org context, it would be cleaner to navigate via the router (either useNavigate or router.useNavigate) and feed it a route constant instead of a literal path. That would also centralize path construction in appRoutes rather than scattering string paths.
• getRedirectPathAfterOrgSwitch already derives the “parent” context; instead of returning /edge/... strings, it could return a ROUTE key (or be split into “determine parent entity type” + “map entity type to route constant”), then this callback could just call navigate(parentRoute). That avoids coupling this component to hard‑coded URLs and the top‑level /overview path.

If you do need to keep the full reload semantics for now, consider at least basing targetPath on ROUTE/appRoutes so future route renames or base‑path changes don’t silently break this redirect.

Also applies to: 89-90, 148-149

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d3fe50e and 560712c.

📒 Files selected for processing (1)

• libs/ui-components/src/components/common/PageNavigation.tsx (3 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: celdrake
Repo: flightctl/flightctl-ui PR: 363
File: libs/ui-components/src/hooks/useWebSocket.ts:54-58
Timestamp: 2025-10-08T11:21:15.680Z
Learning: In flightctl-ui, when organizations are enabled, all API requests require the org_id parameter and fail with 403 if it's missing. This means users can only reach the Device details page (and its Terminal tab) if they have a valid organization selected, so organizationId will always be defined in that context.

🧬 Code graph analysis (1)

libs/ui-components/src/components/common/PageNavigation.tsx (3)

libs/ui-components/src/hooks/useTranslation.ts (1)

• useTranslation (5-8)

libs/ui-components/src/hooks/useNavigate.tsx (1)

• useNavigate (49-72)

libs/ui-components/src/hooks/useAppContext.tsx (1)

• useAppContext (123-123)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: integration-tests
• GitHub Check: Lint
• GitHub Check: Build ocp plugin
• GitHub Check: Build