v0.15.0 — Saved views in the schema

v0.15.0 — Saved views in the schema

Minor release: a new schema field, views, lets the schema author declare named combinations of query, filter and sort. Users pick one from a dropdown at the list head; the active view is mirrored to the normal UI state and persists in settings.views. A startView is applied once at mount.

What this fixes

Before this release, query, filter and sort were ephemeral: closing and reopening the file (or saving and reopening) reset them. Recurring views ("open items for my area", "overdue", "Q3") had to be re-entered by hand every session. The new SCHEMA.views block stores named combinations:

views: [
  { name: 'Open of mine', query: '', filters: { status: 'open' }, sort: { key: 'due', dir: 'asc' } },
  { name: 'Overdue',     query: '', filters: { status: 'open', due: { before: 'today' } }, sort: { key: 'due', dir: 'asc' } }
]

Users can rename, delete, capture the current view as a new one, or mark any view as the start view. All of this lives in the Settings editor (no new tab). The active view, captured views and start view all persist in the data block.

Decisions

• Two persistence layers, intentionally separate: SCHEMA.views is the schema author's proposal (read-only after the schema is shipped). User-captured views live in settings.views so they survive schema updates and can be renamed, deleted, or marked as the start view. A future multi-entity migration moves schema proposals under ENTITIES[key].schema.views; the current format stays backwards compatible.
• Merge: same name = theirs wins, disjoint lists union. applyMerge now accepts an optional { views: { mine, theirs } } and returns the merged list. Disjoint views are appended; renamed or modified views from either side replace by name. No view is silently dropped.
• Start view applied once, not on every state update. A startApplied ref guards the apply: it runs at mount and after the user explicitly switches views, but a sort click does not re-snap the UI back to the start view. This is what makes "open with my start view" predictable without making the UI fight the user mid-session.
• Settings editor, not a new tab. Rename inline, delete with confirm, toggle "open with this view", capture from the current state. Sits in the existing application block of Settings so the navigation surface stays flat.
• i18n strings added in EN and DE as new keys (settings.views*, views.*, view.*). No new language, no copy-edit of existing strings.
• Backwards compatible at every surface. Schemas without a views block behave identically to v0.14.x. The school trip demo gained three preset views (Alle, Zettel ausstehend, Geld offen) so the feature is visible without reading the docs.

For existing users

• Schemas without a views block are unchanged. The dropdown at the list head only appears if the schema declares views, the schema proposes them, or the user has captured some. No schema migration is required.
• Stored views are written to settings.views in the data block. Saving the file persists captured views and the start view. Reopening the file restores them. Nothing in settings.views is lost on save.
• Merge now understands views. When two files are merged (applyMerge), view lists are reconciled by name. Renames and modifications from either side win; the merged list contains the union of disjoint entries. No view is silently dropped. The rule is documented in AGENTS.md and the new wiki page.
• The start view is applied automatically when the file is loaded. No user action required; the start view behaves like the first paint of the list. Users who do not want a start view can clear it in the editor.
• npm test now runs nine suites (the new views suite covers positive merge, negative conflict, applyView mirroring, and robustness against null/empty input).

Consciously not included

• No cross-file sharing. Saved views live inside one file. There is no import/export path for views, no cloud sync, no "team views". This keeps the closed-file guarantee intact: a saved file is the database, and it carries everything it needs.
• No multi-entity views today. view.entity is in the schema shape but not enforced; the current single-entity example is the supported path. The shape is forward-compatible with a future ENTITIES[key].schema.views migration.
• No view-level permissions. Every view is visible to every user of the file. There is no per-view "private vs shared" toggle in this release.
• No view-based automation. A view does not trigger emails, notifications, or background jobs. It is a named read filter, not an action.
• No computed columns in views. A view can filter and sort by existing fields (including computed ones from v0.14.0), but it does not introduce new computed values; that boundary still belongs to the computed field type.

Wiki: https://github.com/m-dohmen/openToolbox/wiki/Saved-Views
Full changelog: v0.14.0...v0.15.0