Brings the snake_case rename (#7) and the app home and Runner (#9).
The developer panel's "open as a new cell" links now target the Runner
app (SqlWorkbenchRunnerAppMetaDataProducer.APP_NAME, prefixed), since
/app/sqlWorkbench is the home dashboard. Tests and README updated; the
changelog entry moves under 1.0.0-RC.3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner spec: the SQL Workbench app home is an information dashboard like
the other app homes, the notebook UI is its own nav entry ("Runner"), and
the nav lists only the main tables; sub-tables are relations on a notebook.
- Home: summary tiles and links, runs per day, recent notebooks, recent
runs, slowest and failed queries, most-used notebooks, shared notebooks,
committed writes, and (admins only) activity by user. Read through core
actions in the viewer's session, so permissions and record locks apply;
honest empty and no-permission states. Full width, inline styles only.
- Runner: sqlWorkbenchRunner child app showing the SQL_WORKBENCH widget
(/app/sqlWorkbenchRunner?notebook=<id>).
- Nav: Runner, sql_workbench_notebook, sql_workbench_execution. Cells,
versions, pinned results and shares stay standard tables (URL, API) as
child lists on the notebook; new Runs child list (notebook -> execution
join, locked to the viewer's runs) and an Open in Runner widget.
- SqlWorkbenchIntegrations: opt-in ESB and Quick Search hooks for the main
tables, no dependency on either module.
- Tests: home widgets (H2 and Postgres), nav structure, child lists,
hooks. README, CHANGELOG, UPGRADE, CLAUDE/AGENTS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add SqlWorkbenchDeveloperPanelProvider (id sqlWorkbench, order 450, icon
terminal), registered by SqlWorkbenchDeveloperPanelsMetaDataProducer via
DeveloperPanelsMetaData. For tables on an allowed RDBMS backend, and users
with the workbench access permission, it shows read-only SELECTs for the
record and its table in the backend's own table/column names (dialect
quoted identifiers, escaped primary-key literal), backend details, and
links that open each query in the workbench (?sql=&backend=, not run).
Build against QQQ 4.1.0-RC.4 (the developer panel contract).
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>
Re-pin the default-active qqq-snapshot profile from qqq-bom-pom
4.1.0-RC.1 to 4.1.0-RC.2 (now on Maven Central) and update the docs.
No SNAPSHOT dependencies.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>