Give every analyst a personal starting view of vulnerability data, built from widgets, saved as named presets, and scoped strictly to the user who created it.
The Dashboard domain lets every user build, persist, and manage personal widget-based dashboards. A custom dashboard is a named, ordered layout of widgets, where each widget maps to one analytics data type and carries its own placement, chart type, date range, and scope. Users hold many dashboards and pick one as their landing view.
The dashboard domain is a configuration and composition layer. It owns only the persisted layout record in the custom_dashboards table and delegates all metric computation to the analytics domain. The same record carries grid positions, per-widget config, and optional global filter defaults.
The hard problem is not drawing charts. It is that every analyst rebuilds the same filtered view by hand, and that personal layout cannot be saved, named, or replayed.
At a glance
- Dashboards: Named widget layouts in custom_dashboards; unlimited per user; one default flag
- Widgets: 8 types, each with grid position, chart type, date range, limit, and optional scope
- Default seed: Empty layout seeds 6 widgets: KPIs, severity, status, trend, top assets, SLA
- Saved filters: query or view presets for 10 entity types; default-first ordering
- Saved queries: Named AdvancedQuery definitions, user-scoped, replayed on demand
- Query safety: Per-entity field whitelist plus a fixed 13-operator allowlist
- Isolation: Every record filtered by user_id; cross-user access structurally impossible
How it works
Personal layouts, filter presets, and saved queries are persisted once and replayed on demand, each owned by and visible only to its creator, so analysts stop rebuilding the same view and never see one another saved state.
A dashboard is a JSON array of widget objects in the layout column, each carrying a grid position, a type, and a config. When a dashboard is created with no layout, the service seeds a six-widget default, and on load each widget fetches live data by calling the widget endpoint with its stored config.
Beyond the dashboard, the saved filter domain lets a user persist named presets for any list page, and the query domain lets a user save and replay structured queries. Every preset and every query is owned by one user, enforced on read and on mutation, with no shared or team-level visibility.
Key capabilities
- Saved filters and saved views. A preset captures either a pure query state, which is filter parameters only, or a full view state, which adds presentation such as column selection, sort order, and layout. A sparse patch writes only supplied fields, so omitted fields keep their current values.
- Default preset, auto-applied. A preset can be flagged is_default so the frontend applies it when the user opens that list page. Results are ordered default first, then by recency, so the active default always surfaces at the top of the saved presets panel.
- Saved and structured queries. The query builder accepts nested AND or OR condition groups, comparison operators, sort, and pagination. A named AdvancedQuery is persisted per user, listable by entity type, and replayed later, so an ad hoc investigation becomes a repeatable view.
- Injection-safe by construction. Field names are validated against a per-entity-type whitelist and operators against a fixed set of 13. Unknown fields are skipped and unsupported operators are rejected, so only whitelisted column expressions ever reach the SQL string.
Use cases
- Build an executive landing view. A security manager creates a dashboard with KPI cards, a severity breakdown, and an SLA overview, sets global company and date defaults once, and flags it as the default so it opens as the landing view on every sign-in.
- Save a recurring findings filter. An analyst filters findings to open critical items in one project, saves the state as a named view preset that also stores column choices and sort order, and flags it default so it auto-applies whenever the findings list is opened.
- Replay an ad hoc query. A pentester builds a structured query with nested AND and OR groups across assets, saves it as a named AdvancedQuery, and replays it later from the saved queries list rather than rebuilding the condition tree by hand each time.
Personal layouts, filter presets, and saved queries, scoped to the user who built them.
