Skip to content

Reset a settings area and list the areas over HTTP - #3126

Merged
pournasserian merged 1 commit into
mainfrom
3098-settings-reset-and-list
Nov 15, 2026
Merged

pournasserian merged 1 commit into
mainfrom
3098-settings-reset-and-list

Conversation

@pournasserian

Copy link
Copy Markdown
Member

Closes #3098

The Management API can now reset a settings area and list the areas. DELETE /settings/{area} and DELETE /settings/{area}/defaults call ResetAsync: the row goes, the level below shows through again, and a site inherits every secret of the defaults again, including when the defaults replace it later. GET /settings lists the areas the caller may manage in the site of the request and for the instance defaults, with the plugin that registers each, so the admin can draw its settings menu. Spec 4.10 and 4.13, the OpenAPI document and the AI assist README describe what was built.

Dependencies

None.

Decisions

  • If-Match on a reset. Required, as on a write: without it the answer is 428 (FCMS3130), and * is refused. The client sends the version it read. "0" with no row changes nothing, raises nothing and answers 204. A row that has moved, or a version other than "0" when there is no row, is FCMS2808 (412).
  • Order of checks. The same as a write: the permission by area name first, so an unknown area is a 403 for a caller without the permission, then the area (FCMS2802), then If-Match. /defaults needs a grant with no site limit.
  • Answer. 204 with no body and no ETag. The next read shows what the reset uncovered.
  • Activity. A reset raises SettingsChangedEvent, so its activity row is settings.changed, as ResetAsync already did. Log line 9803 calls it a reset. The activity row does not tell a reset from a write, because that would change the SDK event.
  • List shape. { "items": [{ "area", "plugin", "site", "defaults" }] }, ordered by area name. plugin is null for an area of core or of the host, not the string core, because a plugin may be named core. An area the caller may manage nowhere is left out. A caller with no settings permission gets an empty list, not a 403.
  • Owner. AddSettings<T>() records the plugin in PluginContributions, the same way jobs and outbox handlers are recorded.
  • Unlisted marker. [UnlistedSettings] is an internal attribute in core, and only SeedingState carries it. It is not public in the SDK, so PublicAPI does not change, and a public marker can still be added later. The routes of seeding still answer a caller that has settings.seeding.manage, as they did before. Only the list leaves the area out, since closing the routes would change behaviour beyond this issue.
  • Plugin enablement. Neither the list nor the routes check whether the area's plugin is enabled in the site. The settings routes never did, and the admin reads enablement from /plugins.
  • No new error codes, log event ids, migrations or PublicAPI entries.

Acceptance

  • A site that set its own ai key inherits the key of the defaults again after a reset, and keeps inheriting it when the defaults replace it
  • A reset needs settings.{area}.manage, as a write does, and answers 204. It changes nothing when there is no document
  • A reset with an outdated version in If-Match is refused with FCMS2808
  • GET /settings lists only the areas the caller may manage
  • The OpenAPI document lists both routes, and spec 4.10 and 4.13 (settings as built) describe them

Tests

  • SettingsResetAndListTests (new, SQLite). After a reset a site reads the secret of the defaults, follows them when they replace it, and keeps inheriting through a write that leaves the key out. A reset of the defaults gives the inherited secret its code default. The class also covers stale and missing If-Match, a reset that changes nothing and records no activity, the permissions of the site and the instance, the list for Super Admin and for site, instance and unrelated roles, and seeding left out.
  • AiProviderTests.ASiteThatResetsItsSettingsInheritsTheKeyOfTheDefaultsAgain: the stub providers receive the site's key, then the defaults' key after the reset, then the replaced key.
  • PluginContributionTests.TheListOfSettingsAreasNamesThePluginOfEach and OpenApiDocumentTests.TheListOfSettingsAreasAndTheResetsAreDocumented.
  • Ran: dotnet build -c Release -warnaserror, the SDK, core and architecture tests, the Management, OpenAPI and seeding integration tests, the plugin contribution and AI provider tests, the data settings tests on SQLite, and markdownlint.

@pournasserian pournasserian added type:feature New capability area:settings Typed settings labels Nov 15, 2026
@pournasserian
pournasserian merged commit 42d7b42 into main Nov 15, 2026
14 checks passed
@pournasserian
pournasserian deleted the 3098-settings-reset-and-list branch November 15, 2026 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:settings Typed settings type:feature New capability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reset a settings area and list the areas over HTTP

1 participant