society-scope

Summary

A user belongs to many societies with a different role in each, so every request names the society, unit and membership it is acting in.

Why it matters

This is a multi-tenant product: one database, many societies. A resident of two societies must never see one society's visitors while acting in the other, and the same person can be an admin in one and a resident in the next.

Implications

• The client sends x-society-id, x-unit-id and x-membership-id on every GraphQL request. ScopeProvider (packages/ui/providers/ScopeProvider.tsx) holds the selection; the mobile unit switcher changes it.
• Resolvers that need a society declare @RequireScope({ requireSociety: true }).
• Services filter by the scoped society automatically (autoFilterBySociety). Geography is the exception: cities, states and countries are global.
• Onboarding queries run before any membership exists, so they pass skipScopeHeaders: true.
• A super admin bypasses the society requirement.
• The mobile app picks its tab set from the role of the selected membership, not from the user — see role-gate.

Related

• roles
• membership
• role-gate
• unit-switcher — where the scope is changed

Sources

• AGENTS.md — "Security requirements", "Quick reference"
• packages/ui/providers/ScopeProvider.tsx
• apps/mobile/src/components/society/UnitSelector.tsx