Kiosk View

Overview

The Kiosk view is a tablet/touch-screen interface designed for shop-floor operators. After PIN authentication, the operator sees a grid of work cards (optionally filtered to their identity — see Filtros por Utilizador below); each card carries live components (timers, counters, workflow buttons) that the operator drives during a shift.

Use it when:

• A single tablet is shared by multiple operators, each authenticated by a PIN at the start of their shift.
• The cards represent the operator's work (orders, tasks, machines) — not a retail menu.
• Workflows triggered from the card should be attributed to the operator, not to the org-level user logged into the tablet.

Concepts

Subuser

A row in a configured Feature representing one operator. The subuser carries a PIN (typically 4 digits, stored plain — kiosk-grade security) and optional sector/role. Identity is propagated to descendants via a KioskSubuserScope so that workflow actions stamp _metadata.subuserId on records they create.

Tabs

Categorisation of the work grid. Tabs are required: a kiosk with no tabs shows no data at all, only an empty state ("Sem tabs configuradas") asking the admin to add at least one. Each tab carries a canonical FilterGroup applied to the visible cards. The active tab index lives in KioskViewState.activeTabIndex and is updated by tapping a tab.

Card action mode

Configurable per view (KioskCardConfig.actionMode):

Mode	Card tap behavior
editForm (default)	Opens the row's edit form
panel	Opens a bottom sheet with configured workflows
liveComponents	No tap action — the operator interacts only with live components inside the card

Shift button (entrada/saída)

A first-class button in the top bar that toggles between "Marcar entrada" and "Marcar saída" based on the operator's last attendance record. Tap dispatches a workflow configured by the admin (typically create_record against an attendance Feature). No new entity — pure Configuration Over Code.

Layout (post-PIN)

┌──────────────────────────────────────────────────────────────┐
│ KioskTopBar    avatar · nome/sector · [shift]    [logout]    │
├──────────────────────────────────────────────────────────────┤
│ KioskTabBar    [ Tab A ] [ Tab B ] [ Tab C ]    (scrollable) │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│    ┌─────────┐  ┌─────────┐  ┌─────────┐                     │
│    │ Card 1  │  │ Card 2  │  │ Card 3  │   <- card grid      │
│    │  timer  │  │  timer  │  │  timer  │                     │
│    └─────────┘  └─────────┘  └─────────┘                     │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Admin configuration

Open the kiosk view's config dialog (admin context). The form is split into sections:

Feature

Choose the Feature whose rows are kiosk subusers, then map the columns:

Setting	Required	Description
Feature de Utilizadores Kiosk	yes	Where subuser rows live
Campo de ID do Utilizador	yes	Stable identifier (stamped to _metadata.subuserId)
Campo de Nome de Utilizador	yes	Display name shown in the top bar
Campo de Senha	yes	The PIN (plain text — kiosk-grade)
Campo de Setor	optional	Sector/role for grouping and per-subuser filters

Filtros por Utilizador

Appears once the Feature section above has a feature selected. Map a column in the work Feature to a sentinel resolved at login: kiosk_user_id / kiosk_username / kiosk_sector. Rows are filtered to match the active subuser at runtime.

Cards

• Campos a Mostrar — which feature columns surface in the card body.
• Filtros — admin-level filters (canonical FilterGroup), applied before per-tab and per-subuser filters.
• Acção ao tocar no card — pick one of the 3 modes above. When panel is selected, configure the workflow list shown in the sheet.

Tabs

Add, edit, reorder, or remove tabs. A new kiosk starts with no tabs at all and only shows content once the first one is added. Each tab opens a dialog with:

Field	Description
Tab name	Label shown on the tab bar
Feature	The feature whose data the tab shows - lists Features from the current workspace plus shared Features from other workspaces of the same organization, sorted alphabetically and labelled with the workspace name in parentheses
View type	The view type that renders the Feature (cards, table, form, etc.); kiosk inside kiosk is not allowed
Operator identity	Only appears once a Feature is chosen - maps columns to the operator's ID, name, and sector, used to pre-fill a new record (applies to form views, with operator login active); if the tab's feature has eligible columns (a single-select Linked Select whose target feature has an Operator column), a Collaborator column field also appears

Once a Feature is chosen, the dialog also shows the Operator filter subsection, which lists the eligible columns of the tab's feature:

• Operator columns - compared directly against the signed-in operator;
• single-select Linked Select columns whose target feature has an Operator column - compared against the mapped collaborator.

Without a signed-in operator, or with an operator that has no mapped collaborator, the tab shows 0 records and displays a discreet warning at the top. The same warning also appears when it's the Collaborator column (the "Operator identity" row above) that has no mapping - the stamp is omitted (empty column) on the created record, not just the filter left without effect.

Field selection, filters, and the card tap action for a tab's content are configured in that tab's own view (see Cards above), not in this dialog.

Shift button

Three dropdowns wire the shift button: a Feature (where check_in/check_out rows are stored), the column that holds the type, and the workflow that performs the write. The Feature dropdown lists Features from the current workspace plus shared Features from other workspaces of the same organization, sorted alphabetically; a shared Feature from another workspace is labelled with the workspace name in parentheses, e.g. "Attendance (Production)". Leaving any dropdown blank hides the button.

Authentication flow

1. The operator lands on the kiosk view (type: 'kiosk'). The router redirects users with kiosk: true in their userConfig to their configured rail; navigation away is reverted.
2. The view fetches the configured kiosk Feature and lists subusers as cards in KioskUserGrid.
3. Tap a card → KioskPinDialog (template AdaptiveDialog).
4. Enter PIN. On match, the dialog dispatches SubuserLoggedIn to KioskSessionBloc and closes.
5. The view rebuilds wrapped in KioskSubuserScope. Descendant components (workflow buttons, create_record action) read the active subuser via KioskSubuserScope.of(context).
6. Logout via the top-bar button dispatches a confirmation dialog and, once confirmed, returns the view to the subuser grid for the next operator.