Settings: retention editor + auto-purge controls (#82) #83

Merged

Cordy merged 3 commits from fix/settings-ui into main

2026-07-30 04:57:28 +00:00

Cordy commented

2026-07-30 04:56:10 +00:00

Owner

Closes #82
Closes #79

Completes the last part of #79 and fixes the v0.3.19 gap.

Auto-purge is now reachable. A checkbox plus a "keep trashed files for" select (30/90/180 days, 1 year) in Settings, bound to trashAutoPurge and trashAutoPurgeAfter. The backend has been there since v0.3.19; until now the only way to enable it was editing settings JSON by hand. The hint text states the guard rails on screen — retention and holds always win, and every automatic deletion is audited — because a destructive setting should explain itself where it's toggled, not only in a changelog.

Retention editor. path = duration textarea bound to retentionPeriods, parsed on the first = so paths containing = survive round-tripping. Reuses the i18n keys added in #79 that were until now unused.

Wired in all three places the settings form requires — markup, openSettings() population, and the PUT /api/v1/settings payload. Since PUT replaces the whole settings object, the payload always sends both new keys; omitting them would silently clear existing retention rules.

Process note. This run started by dumping the actual settings form and handlers instead of guessing at anchors, which is how it landed first try after four failures on the previous issue. The relevant detail that guessing would have missed: openSettings() binds the fetched settings to st, and the load and save sites are ~1300 lines apart. The job also asserts each of the nine expected strings is present after splicing, so a partially-applied patch fails loudly instead of shipping a half-wired form — the exact failure mode that produced #82.

Closes #82 Closes #79 Completes the last part of #79 and fixes the v0.3.19 gap. **Auto-purge is now reachable.** A checkbox plus a "keep trashed files for" select (30/90/180 days, 1 year) in Settings, bound to `trashAutoPurge` and `trashAutoPurgeAfter`. The backend has been there since v0.3.19; until now the only way to enable it was editing settings JSON by hand. The hint text states the guard rails on screen — retention and holds always win, and every automatic deletion is audited — because a destructive setting should explain itself where it's toggled, not only in a changelog. **Retention editor.** `path = duration` textarea bound to `retentionPeriods`, parsed on the *first* `=` so paths containing `=` survive round-tripping. Reuses the i18n keys added in #79 that were until now unused. Wired in all three places the settings form requires — markup, `openSettings()` population, and the `PUT /api/v1/settings` payload. Since `PUT` replaces the whole settings object, the payload always sends both new keys; omitting them would silently clear existing retention rules. **Process note.** This run started by dumping the actual settings form and handlers instead of guessing at anchors, which is how it landed first try after four failures on the previous issue. The relevant detail that guessing would have missed: `openSettings()` binds the fetched settings to `st`, and the load and save sites are ~1300 lines apart. The job also asserts each of the nine expected strings is present after splicing, so a partially-applied patch fails loudly instead of shipping a half-wired form — the exact failure mode that produced #82.

Cordy added 3 commits

2026-07-30 04:56:11 +00:00