RC.4 lets partial edits of child rows pass joined record locks
(qqq#1073), which the table security matrix tests need.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
QQQ's UseTablePermissionCustomPermissionChecker needs a QContext instance
when available permissions are listed and threw a NullPointerException
there (seen in Website-Backend's permission-listing tests). The record
actions now use SqlWorkbenchPermissionChecker, which requires one named
session permission (share-table insert, notebook insert / edit). Test:
listing available permissions with no QContext.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From review of the standard-tables change:
- Versioning: the next number passes both currentVersion and the newest
stored version, the currentVersion update is checked, and failures are
logged (QQQ turns post-customizer exceptions into record warnings).
- Notebook delete cascade: a failed child delete aborts the delete.
- Share visibility sync checks its update.
- An admin ownership transfer resets ownerName to the new owner id.
- Shares are audited at record level, like the other tables.
- Tests: mixed insert/update batches, re-targeting rows into one's own
notebook, planting ownership, a shared reader vs pinned results, and
per-notebook children after denied deletes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
james.maesandClaude Opus 5.5