5 Commits

Include renames

Author	SHA1	Message	Date
NanamiAdmin	c7642ecca5	feat(settings): report which saved keys need a restart ... Every settings update answered with a bare success, so the console could not tell a change that took effect at once from one written to the file that the running program would keep ignoring until it was restarted — the listener address, the storage paths, the Komari dashboard URL. Classify the patch instead. config.RestartRequiredKeys expands a patch into the dot-separated paths of its leaves and intersects them with the settings main reads before it starts serving, and the settings endpoint returns that list as data.restartRequired. It is a pure function of the patch, so UpdateSettings keeps its signature and nothing else has to change; the write succeeds either way, and the field only says which edits are not live. Matching is by overlap rather than equality, so a patch that names a section — replacing it, or deleting it with a null — reports the startup-only keys inside it, while a sibling subtree like webhook.endpoints is not mistaken for webhook.enabled. The result is never nil, so an update with nothing to report serializes as [] rather than null and a client can iterate it without a guard. The console reads the field in ConfigSection and warns instead of confirming, naming the keys that are pending; Settings.vue's hints for the Komari URL, the listen address and the storage paths now say which of their fields is affected rather than labelling the whole card.	2026-09-28 23:28:47 +08:00
NanamiAdmin	d9a9918e21	feat(config): notify reload hooks after a settings update ... A settings update replaced the in-memory configuration but nothing told the code that derives state from it. The logger is the first such consumer: its debug flag is captured once at startup by postLog.SetDebugMode, so toggling system.debugMode at runtime changed what config.IsDebugMode() reported while DEBUG lines stayed filtered by the value from boot. Add a hook registry to the config package. OnReload registers a callback and every writer of config.json runs the registered hooks with the configuration now in effect. It lives in config so packages that already depend on it (the logger, and later the controller manager) can react without config importing them back, which would be an import cycle. Hooks run after settingsLock is released, not inside it. They will rebuild controllers once those support reloading, which can wait on a network call, and settingsLock is also held by the node tracker's background save — running a hook under the lock would stall node registration behind a settings edit. runSettingsUpdate now owns that lock/notify sequence for all four writer paths (UpdateSettings and the three webhook endpoint helpers). A panicking hook is logged and skipped: by then the new configuration is on disk and published, so reporting the write as failed would be a lie, and the hooks registered after the broken one still need to run.	2026-09-28 23:10:33 +08:00
NanamiAdmin	3877c6d128	feat(webhook): implement management API for incoming webhook endpoints	2026-09-24 12:32:22 +08:00
NanamiAdmin	8b43e8b2ea	feat(config): make resolver support null value to delete a ... key.	2026-09-08 23:10:26 +08:00
NanamiAdmin	4eb9abff49	feat: add /api/settings/get, /api/settings/set to modify config in frontend	2026-09-08 22:13:30 +08:00