roboto.domain.dashboards.record
Module Contents
DashboardAccessibility
Bases: roboto.compat.StrEnum
Controls who can view a dashboard.
On create/update requests this is a knob that the server folds into DashboardRecord.owner_principal_id. On DashboardRecord it is a derived computed field — always in sync with the owner principal so API consumers never need to parse the principal string themselves.
DashboardRecord
Bases: pydantic.BaseModel
A wire-transmissible representation of a dashboard
Parameters
data AnyProperties
DashboardRecord.accessibility
Derived from owner_principal_id: organization when owned by the org principal, user otherwise.
Attributes
DashboardRecord.created_by
User ID of the dashboard’s creator. Audit metadata only; ownership is carried by owner_principal_id.
DashboardRecord.dashboard_definition
The dashboard definition as a JSON object.
Opaque to the platform, which stores and returns it verbatim. The definition is self-describing: it carries its own schema version, and the client that understands the schema is the one that reads it.
DashboardRecord.name
Human-readable name for the dashboard. Unique per owner within an organization; dashboards with different owners may share a name, so by-name lookups can match more than one dashboard.
DashboardRecord.owner_principal_id
Principal that owns the dashboard, serialized in the RobotoPrincipal ptype:id format.
org:<org_id> for organization-wide dashboards, user:<user_id> for personal dashboards. This is the sole source of truth for org-wide vs personal — a dashboard is org-wide exactly when its owner is the org principal. Ownership anchors authorization — a personal dashboard is editable by its owner or an org admin, an org-wide dashboard by any org member — and scopes name uniqueness: dashboard names are unique per owner within an organization.
DashboardRecord.revision
How many times the dashboard definition has been written, starting at 0.
A definition-generation counter, not a row version: it advances only when dashboard_definition is replaced, and is deliberately untouched by a rename or an accessibility change. Clients never set it — the server owns it — but they must echo the value they loaded back as base_revision when writing a new definition, so a write built on a stale copy can be rejected rather than silently erasing someone else’s edit.