Apps operativas

Las apps son la superficie donde el operador trabaja. No se “construyen” caso por caso: se configuran combinando las capas que ya modelaste (objetos, acciones, fuentes). Son tres: Inbox, detalle de objeto y Dashboard.

Inbox (/inbox)

La bandeja de trabajo del operador. Elige un tipo de objeto y arma su cola con filtros y orden sobre las properties. El vocabulario de filtros es el mismo de los stateCheck: eq, neq, in, notIn, gt, gte, lt, lte, exists, notExists.

Vistas guardadas (SavedView)

Un operador puede guardar la configuración de una bandeja (tipo + filtros + orden + columnas) como una vista y reusarla sin reconfigurarla. Características:

• Privada por usuario — cada quien ve solo sus vistas.
• Se crea/edita/borra por callable (saveView/deleteView); soft delete.
• El filtro y el orden son client-side (sobre el listado por tipo).

Detalle de objeto

Abrir un objeto muestra sus properties, sus links resueltos a etiquetas navegables, y —lo clave— una sección “Acciones disponibles”: las Actions cuyo affectedTypes incluye este tipo y cuyo permissions.roles matchea el rol del usuario. El operador ejecuta la Action ahí mismo, con el objeto precargado como parámetro.

Dashboard (/dashboard)

Una vista agregada del estado del tenant:

• Conteos por tipo — vía aggregation query (getCountFromServer): el costo no escala con la cantidad de objetos.
• Feeds de actividad — últimas ejecuciones de Actions y corridas de ingesta.
• Costo — el contador de operaciones de Firestore del período (Principio de “costos visibles”).

Roles y qué ve cada uno

Las apps no tienen permisos propios: respetan los roles por organización. Un viewer ve todo pero no ejecuta Actions; un operator ejecuta las que su rol habilita; editor/admin además configuran el modelo. Ver Onboarding.