Ecosire Dashboard Management

This is the installation and configuration guide for Ecosire Dashboard Management. Everything on this page describes the ecosire_dashboard_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.

Technical name	ecosire_dashboard_management
Odoo versions	19.0 (Community or Enterprise)
Current shipped version	19.0.1.4.0
Price	$499 USD — one-time, per Odoo version
Odoo module licence	OPL-1
Category	Productivity / Business Intelligence
Depends on	base, web, mail

Your access rules still apply

Semantic queries run as the requesting user. Model access, field access, record rules, audience, company and drill actions are all checked before any value leaves the server. A dashboard cannot show someone data they could not already open in Odoo.

Requirements

Requirement	Detail
Odoo	19.0, Community or Enterprise. Self-hosted or Odoo.sh — Odoo Online (SaaS) cannot install third-party modules
Odoo apps	base, web, mail — Odoo installs any that are missing
Python packages	None beyond a standard Odoo install
External services	None. No remote data sources and no CDN assets

Installation

1. Copy the ecosire_dashboard_management folder into your Odoo addons path.
2. Restart Odoo, then update the apps list.
3. Search for Ecosire Dashboard Management and install it.
4. Assign the access roles below, then define your semantic metrics before building a board.

Roles

Role	What it does
Viewer	Opens boards they are an audience member of
Manager	Assembles boards and submits revisions for review
Reviewer	Independently approves and publishes a revision
Administrator	Allowlists the semantic definitions and actions everything else is built from

A manager cannot approve their own revision. The reviewer must be a different user.

Semantic definitions come first

Nothing renders until an administrator has allowlisted the business metrics a board is allowed to ask for. A semantic definition names the model, the aggregate, the permitted groupings and the permitted filters.

This is the core safety property: the browser never sends a query. It sends the key of an approved definition plus typed filter values. There is no raw SQL, no Python expression and no domain travelling from the client, so a board cannot be coerced into reading something it was not allowlisted for.

Building and publishing a board

1. A manager creates a board and adds components (KPI, chart, table, narrative) bound to approved semantic definitions.
2. The manager submits the revision. It is fingerprinted with a definition checksum and becomes immutable.
3. A reviewer approves it, then makes that revision live.
4. Restores to an earlier revision remain attributable — the audit lineage is preserved.

Exactly one company owns each board. Cache keys are access-sensitive and invalidation is scoped, so stale values cannot be reused across users, companies, revisions, locale or filters.

Launch packs

Eight capability-aware starting points ship with the build:

Executive Command Center · Sales and Revenue · CRM Pipeline · Finance Control · Inventory Operations · Purchase and Vendor Performance · Store Operations and Connector Health · Exception Center

Packs are drafts, not data

A pack contains no invented business metrics. An administrator binds approved local semantic definitions before a pack goes live. If the underlying Odoo application is not installed, the pack reports an explicit unavailable state rather than inventing a number.

Charts, filters and drilldown

Every block type renders as the visual it names. Bar, stacked bar, line and area charts, doughnut rings, stage funnels and a calendar heatmap (daily buckets over a date dimension) are drawn by the module's own SVG renderer inside the OWL runtime — there is no external chart library and no remote asset. KPI tiles can show a period-over-period delta badge (30- or 90-day window) computed on the same governed read path as the headline value; KPI groups render as value chips and bullets show progress toward their target. Cards carry a reviewed 1–12 column span, so a board's layout is part of its approved definition.

Filter bars narrow only explicitly compatible semantics, using approved typed values. The client cannot submit a widening operator — every filter can make the result smaller, never larger.

Drilldown uses an allowlisted action and a server-built domain. A user who cannot read the target action does not get an elevated path to it.

Snapshots

Bounded aggregate snapshots carry the user, company, revision, filter set, language, timezone, classification, policy, checksum, expiry and legal-hold context they were produced under. That context is what makes a snapshot defensible months later — you can tell exactly whose view of what, under which rules, it represents.

Retention runs through bounded background workers, as do due schedules.

Alerts and exceptions

Threshold alerts deduplicate until reset and re-cross, so a metric hovering on a boundary does not generate a stream of duplicates. Managers assign, acknowledge and resolve exceptions through audited dialogs; none of those dialogs elevate the acting user's rights.

Scheduled delivery

Scheduled payloads are generated separately under each recipient's own user and company context — not once and fanned out. Approval, classification, integrity and access are all rechecked at send time, so access revoked after a schedule was created takes effect on the next send.

A failed transport marks the run failed and is retried idempotently: the retry reuses the same message rather than creating a second one.

A schedule's board is taken from its approved delivery policy, so the pair can never be stated inconsistently. Pick the policy and the board fills in.

A new schedule starts with Enabled switched off so it can be reviewed before it delivers anything — and it stays visible in the Schedules list while it is off.

You find out when a delivery stops

A run that fails or is cancelled records its failure category and raises a to-do activity on the schedule, assigned to the person who requested the delivery policy. One open activity per schedule and failure category — a schedule that runs hourly will not flood the assignee with the same problem.

The activity is deliberately not emailed. The escalation exists because delivery just failed, so routing it back through the same mail transport is the one channel known to be unreliable at that moment. It appears in the assignee's Odoo activity list and on the schedule's chatter, and it names the run and the failure category only — never the values the delivery was carrying.

Export and reporting

CSV export neutralises formula-leading cells, so a value beginning with =, +, - or @ cannot execute when the file is opened in a spreadsheet. Summary, print, PDF, presentation and narrative workflows all reuse the same authorised semantic payload rather than re-querying.

Interface states

The Command Center never turns a problem into a blank screen. It has explicit loading, empty, populated, unavailable and recoverable-error states, each with a clear next step. The error state is sanitised, keyboard accessible, retains stale data and keeps a visible Retry.

Presentation supports keyboard use, screen readers, mobile, dark mode, right-to-left languages and reduced motion. Currency follows the active company; dates and numbers follow the user's language and timezone.

Performance

On the stated QA fixture, a warm six-component board loads within 500 ms and two SQL queries; a cold load within 1,500 ms and twelve SQL queries. Every aggregate is bounded — there are no unbounded scans behind a tile.

Deliberate exclusions

No raw SQL, no Python expressions, no runtime plugins, no public iframes, no remote data sources, no CDN assets, no arbitrary actions, no executable dashboard templates, no cryptographic package signing and no visual drag-and-drop designer. These are design decisions, not gaps — each one removes a class of injection or exfiltration risk.

Troubleshooting

A board shows "unavailable". The underlying application or model is not installed, or the board's schema predates a change. The module marks it unavailable rather than executing something it cannot verify.

A viewer sees fewer rows than a manager. That is correct. Queries run as the requesting user, so record rules apply per person.

A revision will not go live. A different user must review it. Authors cannot approve their own work.

A scheduled send stopped arriving. Open the schedule: a failed or cancelled run leaves a to-do activity on it naming the failure category. POLICY_REVOKED and ACCESS_REVOKED mean the recipient or the policy lost authorisation (access is rechecked at send time); NO_RECIPIENT_EMAIL means the internal recipient has no email address; TRANSPORT_ERROR means Odoo's outgoing mail server rejected the send.

Support

• Documentation: docs.ecosire.com
• Email: [email protected]