feat: app home dashboard, Runner nav entry, main tables only (1.0.0-RC.3) #9

2026-10-12T20:06:18Z

KofTwentyTwo commented

2026-10-12 20:06:18 +00:00

(Migrated from github.com)

For the release captain, for 1.0.0-RC.3. Stacked on #7 (the snake_case rename): it uses the new names everywhere. When #7 merges, GitHub retargets this PR to develop. Don't merge before #7.

What (owner spec)

the app homepage should be a proper information dashboard like the other apps. for the running UI, it should be an option in the nav, like 'Runner'. the tables listed should be the main tables someone would use directly, the sub tables should just be relations. all should work for the esb and quick search.

Nav, before and after

Before	After
SQL Workbench (home = the notebook editor widget)	SQL Workbench (home = dashboard)
SQL Notebook, Cell, Notebook Share, Result Snapshot, Notebook Version, Execution Audit	Runner (`sqlWorkbenchRunner` child app, the `SQL_WORKBENCH` widget), SQL Notebook, SQL Execution Audit

Main tables: Notebooks and the Execution audit. The audit is top level on purpose: it isn't owned by a notebook (ad-hoc runs have none, and it outlives deleted notebooks), and people browse it directly ("who ran what").
Sub-tables: cells, versions, pinned results and shares are child lists on a notebook's record view. They stay standard QQQ tables, reachable by URL and API. The record view adds a Runs child list (new join sql_workbench_notebook_join_sql_workbench_execution, locked to the viewer's runs; admins see everyone's) and an Open in Runner link. Its sections now have plain titles rather than join names.
Runner: /app/sqlWorkbenchRunner?notebook=<id>. No Next change is needed: the existing widget reads ?notebook= wherever it is rendered.

Home dashboard widgets

All real data, read with core actions in the viewer's session, so permissions and record locks decide what each widget counts. Every widget is full width, uses inline theme-neutral styles, and has an honest empty state and a no-permission state.

SQL Workbench tiles: notebooks (yours / shared with you), runs today, runs and failures in 7 days, writes and rows affected in 30 days. Links to the Runner, Notebooks and the Execution Audit.
Runs per Day (30 days): runs, failed, writes.
Recent Notebooks, with sharing and Open in Runner.
Recent Runs: SQL linked to the audit row, notebook, status, duration, rows.
Slowest Queries, 30 Days.
Failed Queries, 30 Days, with the error.
Most-Used Notebooks, 30 Days: runs, users, last run.
Shared Notebooks: audience and since when.
Writes: gated write mode; who, what, when, rows affected, result, and whether write mode is on.
Activity by User, 30 Days: workbench admins only (the widget permission is sql_workbench_admin).

ESB and Quick Search

SqlWorkbenchIntegrations is an opt-in hook with no dependency on qqq-esb or qbit-quick-search:

esbTableNames(config) returns the main tables.
quickSearchTables(config) returns the main tables with weighted fields:
- notebook: title 10, description 5, owner 3, backend 1; basepull on modifyDate
- execution: sqlText 8, executionUuid 5, userName 3, errorMessage 2, backend 1; basepull on createDate

Quick Search re-reads hits through the record locks, and its developer panel then covers these tables too. The README documents what leaves the database: execution events carry the SQL text and parameter values, never results. The kof22 wiring is KofTwentyTwo/Website-Backend (linked below).

Breaking for hosts

/app/sqlWorkbench is now the dashboard; the editor is at /app/sqlWorkbenchRunner. #6 (developer panel) links to /app/{sqlWorkbench}?sql=...; that should point at the Runner app (SqlWorkbenchRunnerAppMetaDataProducer.APP_NAME). UPGRADE.md steps 6 and 7 cover this, and CHANGELOG has the entries under RC.3.

Tests

CI=true ./mvnw verify: 119 unit tests and 8 Postgres integration tests pass (Testcontainers), with checkstyle and the JaCoCo gate.
New tests:
- SqlWorkbenchHomeTest: every widget, locks (own vs admin), the admin-only widget, empty and no-permission states, HTML helpers.
- AppNavigationTest: the nav is the Runner plus the main tables only; no app lists a sub-table; child lists, plain section titles, the Runs list locked and newest first; the ESB and Quick Search hooks, including the prefix.
- PostgresIntegrationTest.testHomeDashboardOnPostgres: the dashboard over real engine runs on Postgres.
Screenshots: light and dark at 390, 1024 and 1440 px of the home, the Runner and a notebook record. Taken locally (H2 demo server, Next main export): no page-level horizontal scroll and no inner scrollers at any width.

🤖 Generated with Claude Code

For the release captain, for **1.0.0-RC.3**. **Stacked on #7** (the snake_case rename): it uses the new names everywhere. When #7 merges, GitHub retargets this PR to `develop`. Don't merge before #7. ## What (owner spec) > the app homepage should be a proper information dashboard like the other apps. for the running UI, it should be an option in the nav, like 'Runner'. the tables listed should be the main tables someone would use directly, the sub tables should just be relations. all should work for the esb and quick search. ### Nav, before and after | Before | After | |---|---| | SQL Workbench (home = the notebook editor widget) | SQL Workbench (home = dashboard) | | SQL Notebook, Cell, Notebook Share, Result Snapshot, Notebook Version, Execution Audit | **Runner** (`sqlWorkbenchRunner` child app, the `SQL_WORKBENCH` widget), **SQL Notebook**, **SQL Execution Audit** | - **Main tables:** Notebooks and the Execution audit. The audit is top level on purpose: it isn't owned by a notebook (ad-hoc runs have none, and it outlives deleted notebooks), and people browse it directly ("who ran what"). - **Sub-tables:** cells, versions, pinned results and shares are child lists on a notebook's record view. They stay standard QQQ tables, reachable by URL and API. The record view adds a **Runs** child list (new join `sql_workbench_notebook_join_sql_workbench_execution`, locked to the viewer's runs; admins see everyone's) and an **Open in Runner** link. Its sections now have plain titles rather than join names. - **Runner:** `/app/sqlWorkbenchRunner?notebook=<id>`. No Next change is needed: the existing widget reads `?notebook=` wherever it is rendered. ### Home dashboard widgets All real data, read with core actions in the viewer's session, so permissions and record locks decide what each widget counts. Every widget is full width, uses inline theme-neutral styles, and has an honest empty state and a no-permission state. 1. **SQL Workbench** tiles: notebooks (yours / shared with you), runs today, runs and failures in 7 days, writes and rows affected in 30 days. Links to the Runner, Notebooks and the Execution Audit. 2. **Runs per Day** (30 days): runs, failed, writes. 3. **Recent Notebooks**, with sharing and Open in Runner. 4. **Recent Runs**: SQL linked to the audit row, notebook, status, duration, rows. 5. **Slowest Queries, 30 Days**. 6. **Failed Queries, 30 Days**, with the error. 7. **Most-Used Notebooks, 30 Days**: runs, users, last run. 8. **Shared Notebooks**: audience and since when. 9. **Writes**: gated write mode; who, what, when, rows affected, result, and whether write mode is on. 10. **Activity by User, 30 Days**: workbench admins only (the widget permission is `sql_workbench_admin`). ### ESB and Quick Search `SqlWorkbenchIntegrations` is an opt-in hook with no dependency on qqq-esb or qbit-quick-search: - `esbTableNames(config)` returns the main tables. - `quickSearchTables(config)` returns the main tables with weighted fields: - notebook: title 10, description 5, owner 3, backend 1; basepull on `modifyDate` - execution: sqlText 8, executionUuid 5, userName 3, errorMessage 2, backend 1; basepull on `createDate` Quick Search re-reads hits through the record locks, and its developer panel then covers these tables too. The README documents what leaves the database: execution events carry the SQL text and parameter values, never results. The kof22 wiring is KofTwentyTwo/Website-Backend (linked below). ## Breaking for hosts `/app/sqlWorkbench` is now the dashboard; the editor is at `/app/sqlWorkbenchRunner`. #6 (developer panel) links to `/app/{sqlWorkbench}?sql=...`; that should point at the Runner app (`SqlWorkbenchRunnerAppMetaDataProducer.APP_NAME`). UPGRADE.md steps 6 and 7 cover this, and CHANGELOG has the entries under RC.3. ## Tests - `CI=true ./mvnw verify`: 119 unit tests and 8 Postgres integration tests pass (Testcontainers), with checkstyle and the JaCoCo gate. - New tests: - `SqlWorkbenchHomeTest`: every widget, locks (own vs admin), the admin-only widget, empty and no-permission states, HTML helpers. - `AppNavigationTest`: the nav is the Runner plus the main tables only; no app lists a sub-table; child lists, plain section titles, the Runs list locked and newest first; the ESB and Quick Search hooks, including the prefix. - `PostgresIntegrationTest.testHomeDashboardOnPostgres`: the dashboard over real engine runs on Postgres. - Screenshots: light and dark at 390, 1024 and 1440 px of the home, the Runner and a notebook record. Taken locally (H2 demo server, Next `main` export): no page-level horizontal scroll and no inner scrollers at any width. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-sql-workbench#9