Dashboards — Developer Index
Entry point for the Enezaframework dashboard developer guides. Start here, then follow the links to the topic you need.
Table of Contents
- What This Series Covers
- The Two Workflows
- Documentation Map
- Suggested Reading Paths
- A Note on Testing
What This Series Covers
The dashboard system is a presentation layer over enezareporting. It never
builds a second query engine: every widget executes an existing registered report
through that report's generator, parameters, filters, computations, and
permissions (enezareporting/dashboard.py:1-6).
This series explains the two things a developer or administrator must do:
- Create a data source — opt a tabular report in to dashboard use, expose useful dimensions and measures, and make it pass authorization.
- Design a dashboard — compose tabs and widgets, either declaratively in code and seed them, or interactively in the browser designer, then publish.
Expected outcome: a published dashboard whose KPI cards, charts, tables, and previews all read live data from registered reports, visible only to users with the right permissions.
The Two Workflows
| Workflow | Best for | What you edit | Where it is documented |
|---|---|---|---|
| Declarative | Dashboards shipped with a business app, reviewed in code, reproduced across environments. | A DASHBOARDS list on the app's AppConfig, then seed_dashboards. |
Defining and Seeding Dashboards |
| Designer | Administrators adjusting a dashboard after deployment, binding wireframe placeholders, previewing, publishing, and rolling back. | Draft versions through /dashboards/manage/. |
Dashboard Designer and Publication |
Both workflows write the same structured models — Dashboard,
DashboardVersion, DashboardTab, and DashboardWidget — and both are
validated by the same publication rules.
Documentation Map
| Pos | Guide | What it covers |
|---|---|---|
| 0 | Dashboards — Developer Index | This page — series map and reading paths. |
| 1 | Dashboards Overview | Concepts, architecture, identifiers, publication, security boundaries, and v1 scope. |
| 2 | Creating a Dashboard Data Source | End-to-end: model → report class → opt-in → metadata → permissions → verification. |
| 3 | Defining and Seeding Dashboards | Declarative definition schema, widget composition, seeding, ownership, and versioning. |
| 4 | Dashboard Designer and Publication | Browser workflow: create, wireframe, bind widgets, preview, publish, versions, preferences. |
| 5 | Dashboard Reference | Complete attribute, metadata, widget, layout, parameter, filter, settings, route, and error-code reference. |
| 6 | Worked Example: frameworkapp | The real FrameworktestdocumentSales report and procurement_overview dashboard, end to end. |
| 7 | Operations and Troubleshooting | Deployment checklist, failure matrix, error codes, and user validation steps. |
Suggested Reading Paths
I need to expose a new report as a data source 1. Creating a Dashboard Data Source 2. Dashboard Reference — Report attributes and metadata 3. Operations and Troubleshooting
I need to ship a dashboard with my app 1. Dashboards Overview 2. Creating a Dashboard Data Source 3. Defining and Seeding Dashboards 4. Worked Example: frameworkapp
I need to design or fix a dashboard in the browser 1. Dashboard Designer and Publication 2. Dashboard Reference — Widget configuration 3. Operations and Troubleshooting
Something is broken 1. Operations and Troubleshooting 2. Dashboard Reference — Error codes
A Note on Testing
Per project rules, the developer or agent does not run tests and does not claim that any step "works" or "passed". The user is solely responsible for all testing and validation of the output described in these guides.