Repository navigation
Typed settings model persisted per site #2704
Description
Problem
Core features and plugins need configuration that administrators can change at runtime per site, with instance defaults and change notifications.
Proposal
Implement [Settings("area")] classes, cms_setting (site_id, key, json, updated_at, updated_by), ISettings<T>.GetAsync(site) resolving site override over instance default over code default, SetAsync raising SettingsChangedEvent, JSON schema generation per settings type for the admin and the Management endpoint, and the permission settings.{area}.manage.
Acceptance
- A plugin settings class is readable and writable per site
- Changing a setting raises an event and invalidates cached readers
- The JSON schema of a settings type is produced from its attributes
Design: docs/planning/backend-technical-spec.md, section 4.13 (item B-33). Size: S.
Activity
pournasserian commentedon Nov 2, 2026
Note from #2738 (#2700):
settings.{area}.manageis one permission per settings area, and this issue is where the areas appear.CorePermissions.Settings(area)builds the name. Add each settings classs permission toPermissionCatalogue, which closes the acceptance item #2700 left unticked. This issue addscms_setting, so followdocs/system-migrations.md.pournasserian commentedon Nov 3, 2026
From #2755. Publishing an event inside a
SystemDbContexttransaction throwsFCMS2602, and there is no API to stage an outbox row in one yet. If settings publish change events from inside a transaction, add that API here; otherwise publish after the commit.