rmancinasandClaude Opus 5
a491ef3eed
NOTIFICATION_ADMIN_EMAILS made "add Beto to the summaries" a redeploy — the wrong unit of work for a list that changes when office staff change. Adds `app_settings`, a key/value table for the configuration staff must be able to change without a deploy, and `SettingsService`, which resolves every key db -> env -> default and reports which of the three a value came from. That ladder is what makes the move safe: a deployment behaves exactly as before until somebody saves in the UI, and the screen can say "this is still coming from the deployment" rather than implying somebody chose it. - new ability `setting:manage` (ADMIN) — deliberately above `notification:send`, since redirecting the audit summaries is how someone would quietly stop them being read - GET/PUT /notifications/settings/admin-emails; read is open to any logged-in user so the UI can display the list, write is gated - resolved per job, not cached at boot, or we would reintroduce exactly the restart-to-apply behaviour being removed - a saved empty list means "nobody" and does NOT fall through to the env, or clearing the field would keep mailing the people just removed Credentials stay in env — see the model doc for where the line is drawn. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
15 lines
506 B
TypeScript
15 lines
506 B
TypeScript
import { Module } from "@nestjs/common";
|
|
import { SettingsService } from "./settings.service";
|
|
|
|
/**
|
|
* Operator-editable configuration. No controller of its own — each setting is
|
|
* exposed by the feature that owns it (summary recipients live under
|
|
* /notifications), so the validation and the permission live next to the
|
|
* thing they protect rather than behind a generic key/value endpoint.
|
|
*/
|
|
@Module({
|
|
providers: [SettingsService],
|
|
exports: [SettingsService],
|
|
})
|
|
export class SettingsModule {}
|