Site settings

The system_admin-only knob room. branding, plan + billing, custom domain, category lists for every queue, color palettes, chat groups, role badges, feature toggles, and payment configuration. one page, many sections.

Who can open it

Site Settings requires the system_admin role. A plain admin doesn’t see the link on the admin panel and is redirected to /admin if they hit the URL directly. The intent is to keep app-wide changes (theme, plan, category lists, feature toggles) on a small blast radius. one or two people per community.

Page layout

On wide screens the page is two columns: the App Config card is on the left and sticks to the viewport, the rest of the sections stack on the right and scroll independently. On narrow screens everything stacks linearly. Each section on the right is a self-contained accordion with its own save button. nothing here is a single global save.

The sections, grouped

Identity & theme. App name, theme preset, custom brand color, surface color, active modes (community / demo). Changes are visible everywhere the app reads app_config on next render.

Plan & billing. Current tier, household count basis, link out to manage subscription on the admin portal. Custom domain (e.g. portal.your-hoa.com) is configured here too. you get DNS records to set on your registrar after saving.

Categories. The dropdown values residents pick from on every form get configured here. architectural review categories (with per-category instructions + required-document prompts + optional fees), maintenance categories, vendor categories, violation categories, document categories. Adding or renaming a value here updates every form that consumes it.

Calendar event types. The display label, locked key, and color for each event-type badge. The locked key means renaming the label is safe; existing events keep their type.

Colors. Topic colors (used on feed pills, notification dots, activity indicators across the app) and banner colors (the system banner backgrounds) each have their own section. The defaults ship from migration; overrides land in app_config and propagate immediately.

Chat sidebar groups. Rename or reorder the groups in the chat sidebar (Management, Committees, Residents, Polls, Archived defaults). Some groups are system-managed (polls + committees + archived) and can be renamed but not deleted.

Integrations. Google Meet OAuth (connect an account so admins can generate meet links from event forms) and Stripe-backed payment settings (the toggle between an external payment URL and integrated Stripe, plus the dues fee note shown to residents on the pay screen).

Roles. Role-badge configuration (avatar ring color for admin, system admin, board member; board member also gets a custom icon next to their name in chat).

Feature management. Per-page on/off toggles for ~22 resident-facing surfaces. Disabling a feature hides its nav item and redirects its URL to /dashboard. Items locked by community-mode display a lock until the mode is cleared.

Why some sections don’t show up

Sections whose underlying feature isn’t included on the current plan are suppressed. there’s no point letting an admin configure architectural categories if architectural review isn’t on the plan. The page reads the hidden-feature set on render; an upgrade puts the corresponding sections back the next time you load Settings.

Audit trail

Every section save goes through an audited server action, so the change shows up in the audit log with the system_admin user, the field name, and the before / after values. The top of Settings has a direct link into the audit log filtered to entity_type=settings, which is the fastest way to answer “when did the theme change” or “who turned this feature off”.