04 — Base Configs
What it is: Global key-value settings for a team's store that don't change when you swap programs. Think: auth token lifetimes, timezone. Stored as JSONB per key, with an audit history table.
Table: tbl_base_configs
One row per config key. Key is unique per schema.
| Field | Notes |
|---|---|
configKey | enum-backed (must be registered before use) |
configCategory | grouping (auth, general, feature_flags) |
value | JSONB — flexible (string, object, array, number, boolean) |
version | increments on each update |
Table: tbl_base_configs_history
Audit trail. Every create/update/delete writes a row here with oldValue, newValue, changeType, and optional changeReason. This backend is read-only for configs — all writes come from the dashboard.
Config keys
| Key | Category | What it controls | Defaults |
|---|---|---|---|
authSettings | auth | accessTokenExpiry ('15m'), refreshTokenExpiry ('30d'), fetchVendorData | see defaults |
generalSettings | general | timezone (e.g. 'America/New_York') | America/New_York |
featureFlags | feature_flags | runtime feature toggles | {} empty |
Note: Inventory seat limits were moved to
tbl_flex_program_configs(per-program), not here.
How retrieval works
- Missing config key → falls back to code defaults in
base-config-defaults.constant.ts - Partial DB values are deep-merged with defaults (all properties always present)
- Soft-deleted configs also fall back to defaults
Key rules
- This backend only reads configs; dashboard writes them
- Config keys must be in the
BaseConfigKeyenum (generalSettings·authSettings·featureFlags) before use - No
teamSchemacolumn — multi-tenancy is handled by schema isolation (one schema per team)