Dashboard Configuration

The home dashboard (the page you land on after login) is driven by a single YAML structure stored in the DASHBOARD_CONTENT configuration entry (Home app), computed by app_home/dashboard.py. Each top-level item is a section; each section groups a list of schema / app / link cards.

DashboardApp (Django admin) no longer drives the home page - same transition the sidebar already went through, see Sidebar Configuration. A Beta Preview dashboard-mockup UI prototype (Admin Tools > UI Prototypes, requires BETA_PREVIEW=yes) is also available as a static layout reference (not live data) if you just want to see the section/ card styling without touching your real DASHBOARD_CONTENT.

Editing

• Go to Configuration in the sidebar, then the Home tab.
• Edit the DASHBOARD_CONTENT textarea and save.
• The YAML is validated on save - an invalid structure is rejected with an error, nothing is written.
• Clearing the field entirely and saving resets it to the built-in default rather than saving a blank dashboard.
• Changes take effect immediately for the saving user. Other already-logged-in users may see the previous dashboard for up to ~1 minute (short per-user cache).

Permission needed: p_conf_admin

Item types

Every section is a YAML mapping with a section key and an entries list. Every entry inside entries is a mapping with exactly one of these keys: schema, app, link.

section

- section: "Tools"
  entries:
    - app: import
    - app: export

• label (optional) - header text. Defaults to the section value itself.
• entries - a list of schema / app / link items.
• A section with zero visible cards (e.g. everyone lacking the required permission) is dropped entirely - its header is never shown on its own.

schema

A compact card with the schema’s icon, object count, and display name, linking to its instance list.

- schema: laptop
  label: "Laptops"

• Visibility is not configurable here - it always follows the schema’s own read permission, so a dashboard card can never expose a schema the current user couldn’t otherwise access.
• label (optional) - defaults to the schema’s display name, then its keyname.
• icon (optional) - defaults to the schema’s configured icon.

Special values, both of which must be quoted - ! and @ are YAML reserved indicators, so unquoted !name or @ALL do not parse as plain strings and will break the whole document:

• schema: "@ALL" - expands to every schema not already named (positively or negated) anywhere in the document, across every section, still subject to normal read-permission checks. Order follows the schema list’s own configured order. Deliberately not called all_schemas or * - that would be easy to confuse with the app: all_schemas entry below, which links to a page listing schemas rather than inserting a widget per schema.
• schema: "!name" - renders nothing by itself. It only marks name as excluded from every "@ALL" expansion in the document, wherever "@ALL" appears.

- section: "Assets"
  entries:
    - schema: laptop
    - schema: "!sirene_message"
    - schema: "@ALL"

app

A card linking to one of Cavaliba’s built-in entry points, identified by a fixed keyname - the same registry the sidebar’s app: entries use. See App Widgets for the full key table. Unlike schema cards, app cards show no object count.

- app: import
- app: ipam
  icon: 'fa-plus'
  label: "Custom IPAM label"

• label, icon, permission (all optional) - override the registry default for this entry only.
• An unknown app key is skipped (logged as a warning) rather than breaking the dashboard.

link

A raw URL, absolute or relative, with an optional permission gate. No object count.

- link: "/path/to/a/link"
  icon: fa-plus
  label: "my label"
  permission: p_this_link_allowed

• link - the URL, used as-is (never resolved/rewritten).
• label (optional) - defaults to the URL itself.
• icon (optional) - defaults to a generic icon.
• permission (optional) - if omitted, visible to any authenticated user.

Full example

- section: "Services"
  entries:
    - app: sirene
    - app: ipam
    - app: sms
    - app: status

- section: "Assets"
  entries:
    - schema: laptop
    - schema: "!sirene_message"
    - schema: "@ALL"
    - app: all_schemas

- section: "Tools"
  entries:
    - app: import
    - app: export
    - app: configuration

Error handling

• On save: the YAML is parsed and structurally validated (must be a list of sections, each section needs a section key and a list entries, each entry must have exactly one of schema/app/link, app keys must exist in the sidebar’s app registry). An invalid submission is rejected and nothing is saved.
• At render time: as a safety net for anything validation can’t catch (e.g. a schema deleted after the dashboard was saved), a parse/lookup error falls back to an empty dashboard for regular users, or a single “Fix dashboard configuration” card (linking to this Configuration page) for admins - instead of breaking the page for every user.

Upgrading from an older version

Versions before this feature grouped the home page’s tiles via DashboardApp entries’ own dashboard_section field (Django admin / builtin YAML). On upgrade, DASHBOARD_CONTENT is seeded from the built-in default shown throughout this page - there is no automatic conversion of prior dashboard_section groupings, so any customization made through the old system must be reproduced by hand in the new YAML. DashboardApp itself still exists (Django admin only - it can no longer be imported/exported via YAML or the cavaliba CLI); it no longer drives the home page.