Centre switching & multi-centre scoping

Platform & Access · Centre switching & multi-centre scoping

The navbar centre picker sets the active centre, which scopes virtually every list query (filter.center_id), drives which modules are enabled and therefore which menu entries and features exist at all.

Area	Platform & Access
Routes	(application-wide)
Centre modules	always available
Staff levels	admin
Models	center · modules
UI label	menu.navbar.configuration.my-center
Coverage	3 use cases · 1 happy · 3 failure

Known issues (1)

• 🟠 Medium — Missing centre cookie produces unscoped queries

How it works

This is the single most load-bearing cross-cutting concern in the app. nf-navbar#centers returns all centres for admin and only auth.centersAvailable otherwise. nf-navbar#menu filters each section by role (section.levels), by module (has<Module>), by disabledByModule, or by an ember-can ability when section.ability is set. Dashboards are injected into the menu dynamically from auth.dashboards. Centre selection is a cookie, not session state, so it survives reloads but is also shared across tabs.

Use cases

Why someone opens this (3)

• A group-level admin comparing or administering several shopping centres from one login.
• Enabling a feature for one centre only — e.g. Yardi, Fideliza or the lottery module — without a code change.
• A store-level user restricted to a single centre and its stores.

Path map

flowchart LR
    F(["Centre switching and multi-centre scoping"]):::feat
    F --> H1["Switch active centre"]:::ok
    F -.-> X1["Module disabled"]:::bad
    F -.-> X2["Role lacks the level"]:::bad
    F -.-> X3["Stale cookie pointing at a lost centre"]:::bad
    classDef feat fill:#4a5c8a,stroke:#4a5c8a,color:#ffffff,font-weight:bold
    classDef ok fill:#e3f1ea,stroke:#0d6b42,color:#0d4a2e
    classDef bad fill:#f7e6e2,stroke:#9a2d1c,color:#6e1f13

Happy paths

Switch active centre

1. Admin opens the centre dropdown in the navbar.
2. Picks another centre; auth.center setter writes the new cid cookie.
3. Menu recomputes from the new centre’s modules and the user’s role.
4. Subsequent list queries carry the new center_id as a fixed filter.

Failure paths

Module disabled

Cause — Centre does not have the module that guards a section.

What happens — The menu entry is filtered out and the corresponding route’s ability check (canAccess) blocks direct URL entry.

Role lacks the level

Cause — section.levels does not include the user’s role.

What happens — Entry hidden; route-level can checks reject manual navigation.

Stale cookie pointing at a lost centre

Cause — cid references a centre the user no longer has access to.

What happens — auth.center resolves to undefined via findBy, and downstream get(center, 'has…') checks fall back to false, producing an app with almost no menu rather than a clear ‘no access’ message.

QA checklist

Tick these off while regression-testing this feature. The boxes are plain Markdown, so progress is visible in git diffs.

• ✅ Switch active centre
• ⛔ Module disabled
• ⛔ Role lacks the level
• ⛔ Stale cookie pointing at a lost centre

Implementation

• app/services/auth.js
• app/components/nf-navbar.js
• app/utils/get-side-nav-menu.js

Translation keys (2)

Key	English
menu.navbar.configuration.my-center	My center
menu.navbar.configuration.centers	Centers

Related

• Same area — Staff login · Password reset request · Password update from reset link · Change own password · Idle auto-logout · Server-incident banner · Desktop (home dashboard) · Runtime environment & white-label boot · Back-office interface language · In-app help & support chat (Froged)
• Shares data with — Centre editor (modules, app config, integrations) · Centre list & export · Staff member list, deletion & restore · Staff member editor (levels, scope, API token) · Customer login methods (Google, Facebook) · Role & module permission layer

---

Generated from doc/feature-inventory.json · id platform-center-switching · commit 276788ca6