Publishing and Permissions
Dashboard Hub separates authoring, viewing, publishing, and exporting so the same hub can serve builders and consumers with different rights.
Permission model overview
Features are seeded into IAM and composed into roles. The client shows or hides UI based on the logged-in user's resolved feature set.
Baseline behaviors such as preferences, widget-type registry reads, and container templates are generally available to authenticated users and are not modeled as optional hub features.
Inheritance rules
| If a user has… | …they also get |
|---|---|
| Hub access | Implicit read of dashboards/containers/widgets in that hub |
*.widget.create | Implied *.widget.add |
Write, publish, and export remain explicit.
Feature families per hub
Each hub follows the same pattern. Examples below use Default Hub and Observability Hub.
Manage
Full authoring for that hub (scope varies by hub type):
| Permission examples | Allows |
|---|---|
default-hub.dashboard.manage | Create/update/delete dashboards in Default Hub |
default-hub.container.manage | Manage containers on those dashboards |
default-hub.widget.create | Create/edit/delete widgets and add them to containers |
default-hub.widget.add | Add existing widgets and read widget runtime data |
*.rearrange.containers / *.rearrange.widgets | Reorder layout (also used by view roles for personal layout) |
default-hub.datasource.mock | Use Mock / Direct Data in Default Hub |
Domain hubs such as Observability may grant manage-as-organize rights (view unpublished + rearrange) without full create/delete, depending on seeded features.
View
Read-only consumption of published content, plus personal rearrange when granted:
| Permission examples | Allows |
|---|---|
default-hub.dashboard.view | View published Default Hub dashboards and live widget data |
observability-hub.dashboard.view | View published Observability Hub dashboards |
Publish
Standalone publish control so publishers need not be full authors:
| Permission examples | Allows |
|---|---|
default-hub.publish | Publish/unpublish Default Hub dashboards and assign users |
observability-hub.publish | Same for Observability Hub |
Export
Standalone export capability for structure or widget data (dedicated export endpoints may be phased):
| Permission examples | Allows |
|---|---|
default-hub.export | Export from Default Hub |
observability-hub.export | Export from Observability Hub |
Publish flow
Typical publish steps:
- Finish authoring and validate widgets against live sources.
- Use Publish (requires publish feature for that hub).
- Assign the dashboard to the intended users or audiences.
- Consumers with view rights open the published dashboard from the hub.
- Use Unpublish when the view should leave circulation.
Publish is intentionally independent from Manage so a reviewer/publisher role can exist without broad edit rights.
Role design tips
| Audience | Suggested feature mix |
|---|---|
| Dashboard authors | Manage + Publish for Default Hub (and needed domain hubs) |
| Domain operators | View + rearrange for their hub; optional Export |
| Publishers / leads | Publish without full Manage |
| Executives | View-only on curated hubs |
Keep Default Hub tightly controlled if it is your unrestricted authoring space, and publish polished boards into domain hubs for wider audiences.