[FR]: opt-in action to refresh default view .base files to current version

[businessBoris]

Feature Description

Use case

I run the stock default views and never edit the generated .base files in TaskNotes/Views/. When a release ships improved default view definitions, my on-disk copies stay on the old version, because existing files aren't overwritten. The documented way to pick up the new defaults is to delete the files and restart (or use "Create default files"), which I have to repeat by hand after every release I want to track.

Proposed solution

Add an explicit, opt-in action — e.g. "Refresh default views to current version" — that overwrites the stock default .base files with the current version's definitions. Keep the existing no-overwrite behaviour as the default, so anyone who has customized their views is never clobbered. This would be a deliberate, confirm-dialog action aimed at users who run vanilla defaults.

Bonus

If that action were also exposed as a command-palette command (and/or via the HTTP API), it could be triggered by hotkey or the Obsidian CLI, which fits the existing TUI/API automation surface. In effect it automates the "regenerate default files and diff" workflow the docs already recommend.

[callumalpass]

Thanks @businessBoris. TaskNotes 4.10.1 adds three explicit opt-in surfaces for refreshing configured default .base files from the current TaskNotes templates/settings. The command palette now includes TaskNotes: Update default base files and uses the same confirmation prompt as Settings -> TaskNotes -> Views & base files -> Update files. Companion plugins can call api.bases.updateDefaultFiles(), and HTTP API clients can call POST /api/bases/default-files/update. The startup/default behavior still does not overwrite existing files unless one of these update actions is explicitly run. I am closing this as completed.

[businessBoris]

Thanks, Callum — this is more than I asked for, and the parts I didn't ask for turned out to be the best bits.

The command-palette action and the HTTP API / api.bases.updateDefaultFiles() are the surfaces that really matter: they make refreshing the defaults scriptable and hotkey-bindable in a way the settings button alone never could. I'd actually written off driving this from the Obsidian CLI as impossible, precisely because there was no command to call — so quietly exposing one solved a problem I'd parked. The opt-in-with-confirmation design is the right call.

One feather-light thought for whenever Bases settles down — no rush, and entirely your call: for people who don't customize the default .base files and just want the latest templates after an update, an opt-in "Auto-update default files on plugin update" toggle (default off, sitting beside the existing "Auto create default files") would give them that flow automatically, without exposing anyone who does customize to surprise overwrites. The explicit surfaces you've added already cover the manual case well; this would just be the lazy-but-safe path for the rest. Either way, thanks for turning this round so quickly.

Also — I'd genuinely like to buy you a coffee for creating the entire project (and turning this round so fast). If you have a buy-me -coffee type link anywhere, point me at it; if not, take this as a standing offer. It's really well documented and exactly what I was looking for to replace my existing manager and especially because I can document what's going on with any task. Until I discovered this project, I couldn't find anything that fitted me and took advantage of Obsidian.

Thank you very (very) much.