v2.9.3 — settings you switched on, where you can see them
Both of these come out of one long night on #2, where @famewolf and @NotRetarded spent four hours together chasing a setting that was working perfectly.
Simple mode no longer hides settings that are switched on
He had auto-cleanup running at 85% on three hosts and could only see it on one. The other two were in simple mode, where that control sits in a block the stylesheet hides. The setting was doing its job the whole time — it just was not on the page to look at. He found it himself in the end, and his conclusion is the right one:
If I have things enabled but can't see them in the gui how would I know to change them?
Simple mode is meant to be fewer knobs, not "your server is doing things you cannot see". Hiding an option nobody has touched is fine. Hiding one that is active is not.
So in simple mode the Settings page now opens with a short list of exactly those — every hidden setting that is not at its default, with its value — and a button that switches to advanced. It reads that list back out of the page it just rendered, rather than from a hand-kept list of which settings count as advanced, so moving a block around cannot make the two disagree. An untouched install sees nothing at all.
An overruled environment variable can be taken back with one click
He hit this three times in one night — DISK_WARN_AUTO_CLEANUP, WEB_PASSWORD and BOT_LABEL — and asked a fair question:
I would think environment variables should have priority?
The precedence stays as it is. Flipping it would silently reset everyone who set something in their compose file once and later changed it in the Web UI, which is a worse surprise than this one. What was missing was a way back that isn't "hand-edit settings.json inside the volume".
The Settings page now lists every variable a saved value is overruling, both values side by side, and a button to take the environment's. It writes that value in rather than deleting the key — which is what makes it stick, because a save writes every setting at once, so a key merely removed comes back the next time you change anything.
Secrets are named and never shown. The value itself never leaves the config object either: a first draft carried it in the entries the interface iterates over, and the existing env-override test caught the leak by serialising one.
Nothing to do on upgrade.
