Skip to main content
CanvasView stores a user-customised investor-report canvas layout for a workspace. One active row exists per (workspace, template_id) pair, enforced by a partial unique index on deleted_at IS NULL. The entity is REST-only and is not tracked in Hasura; the financial-overview page fetches one row by template via PUT /v1/workspaces/:id/canvas-views/:template_id (upsert). It belongs to a Workspace and optionally records the People who created it.
Internal object. Not currently exposed on the public REST API. The operations below describe the intended contract.

API operations

Data model

Attributes

Relationships

System-computed

  • canvas_view_id: auto-assigned via gen_random_uuid() default at row creation — never client-provided
  • created_at: set once by MikroORM onCreate hook (new Date())
  • updated_at: set by onCreate and onUpdate hooks on every write
  • deleted_at: set by the service layer on soft deletion; null for active rows
  • pk: internal auto-increment serial primary key — never exposed in the API
  • Partial unique index idx_canvas_views_workspace_template_active enforces at most one active row per (workspace_pk, template_id) while allowing soft-deleted history rows to coexist
  • The write path is an upsert keyed on (workspace, template_id) — the service resolves or creates the row rather than requiring the caller to supply canvas_view_id
  • blocks validation is fully service-layer enforced (1-7 entries, unique slot_ids, valid widths, position permutation) — no DB-level CHECK constraint on the JSONB column
  • The read formatter (canvas-view.formatter.ts) drops unknown slot_id entries rather than throwing — forward-compat for future slot registry expansions

Example

Source: apps/api/src/database/entities/CanvasView.ts · domain: workspace · tier: Infrastructure