Dashboard Analytics and Widgets

Description

Dashboard Analytics and Widgets turn Dotabase queries into reusable stat, chart, and distribution widgets arranged on a validated 12-column canvas.

Each saved widget carries a typed aggregate query, display configuration, and grid position under its parent view. The view service validates and persists that contract, while the aggregate runner compiles tenant-scoped batches instead of loading rows into a client for calculation. New dashboards can derive a deterministic starter set from the live schema, giving useful measures without claiming that every property can support every visualization.

User Story

As an operations manager, I assemble live counts, trends, and breakdowns directly above the records they summarize. I create a dashboard view, keep the relevant starter widgets, and add a breakdown using the same filters as the underlying records. The server evaluates the aggregates inside my tenant boundary and the view retains the layout. I walk away with a repeatable operational snapshot rather than a spreadsheet export that drifts from the source.

Extension Surface

Configurable: users compose supported widget types, measures, groupings, filters, and layouts.

packages/dotabases/src/services/dotabase-view-service.ts exposes validated widget inputs as the customer-facing configuration surface. Callers choose among shipped widget and query shapes; registering arbitrary renderers or executing custom chart code is outside this package.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: The package owns widget data and validation, not the visual frontend renderer. Starter widgets depend on available schema types. It can run supported aggregate batches, persist several widgets per view, validate layouts, and derive schema-aware starters. It cannot render pixels, infer a meaningful measure for every custom field, or bypass the query DSL's operator constraints. Large analyses also remain bounded by the database query and pagination contracts.

Implementation Map

• packages/dotabases/src/services/dotabase-view-service.ts
• packages/dotabases/src/services/aggregate-runner.ts
• packages/dotabases/src/starter-widgets/index.ts

Related Features

Uses Saved Dotabase Views, Rollup Properties, and the Typed Query DSL.

Operationally, these relationships preserve a clear ownership boundary around Dashboard Analytics and Widgets. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/services/dotabase-view-service.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.