StorageService.patchConfig returns early when canPersist() is false, but nothing upstream of it knows. DisplayComponent.saveAllSettings() calls every setter and then shows the "Configuration saved" toast unconditionally, and no component under src/app/core/components/settings/ gates on isReadOnlySession or canPersist. app.routes.ts gates /settings only with embedBlockedGuard, so an anonymous or read-only visitor reaches the form, changes a setting, presses Save, and is told it worked. The change holds for that session and is gone after a reload.
This is pre-existing and shared by every display setting, and it surfaced while reviewing #610 rather than being caused by it. What that PR changes is the consequence for one setting: "Keep the toolbar on screen" is the documented way out of a page whose widget swallows every reveal gesture, so on an unauthenticated kiosk showing a chart-plotter page — the exact deployment its help text describes — the recovery path is the thing that silently fails to stick.
Two ways to close it, either acceptable: gate the Save action (or the individual controls) on StorageService.canPersist(), or keep the form live and report the dropped write instead of showing a success toast.
Note the out-of-band workaround that already exists and should stay documented either way: an operator can bake pinToolbar into the shared global "default" slot, which is the only config an anonymous principal reads.
Files: src/app/core/components/settings/display/display.component.ts (saveAllSettings), src/app/core/services/storage.service.ts (patchConfig, canPersist), and the sibling settings components that share the pattern.
StorageService.patchConfigreturns early whencanPersist()is false, but nothing upstream of it knows.DisplayComponent.saveAllSettings()calls every setter and then shows the "Configuration saved" toast unconditionally, and no component undersrc/app/core/components/settings/gates onisReadOnlySessionorcanPersist.app.routes.tsgates/settingsonly withembedBlockedGuard, so an anonymous or read-only visitor reaches the form, changes a setting, presses Save, and is told it worked. The change holds for that session and is gone after a reload.This is pre-existing and shared by every display setting, and it surfaced while reviewing #610 rather than being caused by it. What that PR changes is the consequence for one setting: "Keep the toolbar on screen" is the documented way out of a page whose widget swallows every reveal gesture, so on an unauthenticated kiosk showing a chart-plotter page — the exact deployment its help text describes — the recovery path is the thing that silently fails to stick.
Two ways to close it, either acceptable: gate the Save action (or the individual controls) on
StorageService.canPersist(), or keep the form live and report the dropped write instead of showing a success toast.Note the out-of-band workaround that already exists and should stay documented either way: an operator can bake
pinToolbarinto the sharedglobal"default" slot, which is the only config an anonymous principal reads.Files:
src/app/core/components/settings/display/display.component.ts(saveAllSettings),src/app/core/services/storage.service.ts(patchConfig,canPersist), and the sibling settings components that share the pattern.