Layouts, Sidebars & Access

Two page properties sit outside the component tree: layout wraps the body in chrome, and access decides who is allowed to load the page at all.

The layout Block

layout currently holds one key, sidebar — an array of sidebar sections rendered in the page's <aside>. Each section binds to a table and emits one entry per record.

template is where the per-record expressions live:

activeIndicator accepts exactly one value — $currentUser.activeAssignment — which marks the entry matching the tenant switcher's current scope.

pages:
  - name: Workspace
    path: /workspace
    layout:
      sidebar:
        - dataSource:
            table: projects
            sort: [{ field: name, direction: asc }]
          template:
            label: '$record.name'
            href: '/workspace/$record.slug'
            archivedField: archived
          activeIndicator: '$currentUser.activeAssignment'
    components:
      - { type: container, element: main }

Data-Bound Sidebars

A sidebar filtered on $currentUser.assignments.<table> renders only the records the signed-in user is assigned to; a global admin (isUnrestricted) sees them all. Unlike a page-level data source, a sidebar section that cannot resolve its $currentUser reference is dropped silently rather than failing the request — the page still renders, minus that section.

Access Control

access gates the page. It takes one of four forms:

A role-array entry may also be a group reference, group:<name>, validated against app.auth.groups.

pages:
  - name: Billing
    path: /billing
    access: { require: authenticated, redirectTo: /login }
    components:
      - { type: text, element: h1, content: 'Billing' }

What a Denial Returns

Related Pages

• Pages Overview — the full page property table.
• Data Binding — $currentUser scoping and its 401.
• Roles & RBAC — the role names access accepts.
• Groups — the group: references access accepts.
• Layout Components — the sidebar component rendered inside the body.