Settings and Operations
Settings and Operations
Overview
Settings and operational administration are database-backed in CMS v2. Platform operators manage runtime settings, themes, notification delivery, backups, jobs, updates, and selected feature flags from the portal.
Settings Categories
Active settings categories include:
| Category | Typical contents |
|---|---|
| Authentication | JWT, activation, MFA, and federated login settings. |
| Backup | Backup provider, tooling, storage, and retention settings. |
| Billing | Invoice settings, invoice visibility, billing mode, and billing usage selection. |
| Notifications | Email provider, SMTP, Graph, budget alert, and template settings. |
| Platform | Defaults, self-provisioning, region retention, quotas, timezone, and platform options. |
| Portal | Portal shell settings, titles, login options, and display configuration. |
| Updates | Update enablement, channel, updater API key, and deployment metadata. |
Full settings reads require platform roles. Updates require PlatformAdministrator. Non-platform portal users receive only whitelisted non-secret shell feature flags.
Settings Page
The Settings page is available at /settings for platform roles. It uses tabs for Backend, Billing, Platform, Portal, and Themes.
Settings are edit-only records. The portal does not create or delete settings rows.
Secrets
Secret settings are encrypted before persistence, masked in API responses, and preserved when the mask value is submitted unchanged.
Examples include SMTP password, Graph client secret, Azure Storage connection string, updater API key, and other deployment credentials.
Themes and Branding
The Themes tab lets platform administrators create, edit, validate, delete, and select database-backed portal themes. Theme JSON uses MudTheme JSON, not raw C#.
Branding assets can include app bar logo, login logo, and login wallpaper. Missing database assets fall back to static portal assets.
Notifications
Administration > Notifications manages delivery settings and notification templates.
Supported delivery areas include SMTP, Microsoft Graph, operational toggles, and template test sends. SMTP test validates connectivity and STARTTLS negotiation when enabled; it does not send an email.
Notification templates are platform-scoped records. Reads are limited to platform roles, while updates and test sends require PlatformAdministrator.
Backups
The Backups page is available at /backups for platform roles. It lists stored backups and exposes manual run, refresh, restore, provider settings, storage settings, and connection tests.
Backup files are named with backup timestamp and tier. Manual and pre-restore backups are not removed by scheduled tier cleanup.
Retention uses a roll-up model where lower tiers retire after a higher tier exists for a later backup date, with configured retention counts still capping active tier windows.
Restoring a backup creates a pre-restore safety backup first.
Timezone and Localisation
CMS stores operational timestamps in UTC. The portal displays timestamps using the user's timezone where set, otherwise Platform > General SystemTimeZoneId, otherwise UTC.
The localisation feature defines English as default and French as the first additional language. MudBlazor component translations use MudBlazor translations, while CMS-owned text should use application resources.
Documents and Terms
Documents and terms are managed through platform document APIs and portal document surfaces. Required documents can block normal portal use until accepted.
New subscription terms are checked during subscription creation using tenant and region scope priority: tenant, selected region, all regions, then platform.
Operational Notes
Database-backed settings are the source for runtime configuration. API and Portal startup do not create or backfill required database setting rows from appsettings.
Take a full MySQL backup before applying settings, themes, notification, backup, timezone, quota visibility, billing usage selection, update, or document scripts.
Known Gaps
Manual Review Required: Feature documents include several deployment script notes. Confirm each target environment has applied the required scripts before treating all portal settings and operational pages as complete.