Files
james.maesandClaude Opus 5.5 ddd85ebe0d feat(#3): expose workbench data as standard QQQ tables secured by record locks
Notebooks, cells, versions, pinned results, shares and the execution
audit are now ordinary QQQ tables in the SQL Workbench app (nav children,
record views with child lists, edit, export, audits, developer mode)
instead of hidden admin-only tables.

- Record security locks (core-enforced, so every entry point): owner OR
  share audience for notebooks and their children (through joins), the
  audit by user; admins hold sqlWorkbenchAllAccess. Key types
  sqlWorkbenchUser / sqlWorkbenchAudience, applied to sessions by
  SqlWorkbenchSecurity.applyToSession (no keys without workbench access).
- New sqlWorkbenchNotebookShare (USER / GROUP / ALL); publishing writes an
  ALL share and visibility follows the shares.
- Per-table read/insert/edit/delete permissions, listed per role by the
  config (user / share / admin).
- Table customizers hold the notebook invariants for the notebook UI and
  the tables alike: owner from the session, cell validation and order,
  one version per change, share keys, append-only versions and audit
  (admins included), pinned results only from pinning, cascades.
- NotebookService and history run as the caller through the same actions;
  explicit owner/share checks stay as defense in depth.
- Record actions: Share Notebook, Duplicate Notebook, Restore Version.
- DDL: share table plus an idempotent backfill of library shares.
- Tests: TableSecurityMatrixTest (role x table x action over the v1 table
  API, core actions, export, PVS, record actions, notebook endpoints) and
  a PostgreSQL lock test. Docs: README, DESIGN, CHANGELOG.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 06:08:10 -05:00
..