portalPen: staff triage surface (read, answer, assign, resolve tickets)
Staff have NO surface at all. supportTickets carries assignedTo/resolvedBy/resolvedAt and supportTicketMessages carries isInternal, all unused by app code: the only route that touches tickets is the client-side /portal (create + own-queue read). A ticket filed today can be read by nobody, answered by nobody, assigned to nobody and closed by nobody. The portal empty state even tells the client "el estado lo actualiza el equipo" and the team has no place to do it. Needs: staff queue list across appKeys, ticket detail, threaded reply writing to supportTicketMessages (isInternal toggle), assign, status transition through the supportTicketCategoryStatuses matrix (never a hardcoded status list), resolve. Authz: staff group, NOT client. Class-A - new authz predicate on a co-tenanted table.
Questions
Activity
-
Shipped 2026-08-14 at 91aa552; tracker was stale six days, my miss. Delivered at /soporte: staff queue across every app the actor administers (page.tsx), ticket detail (\[id\]/page.tsx), threaded reply writing supportTicketMessages with an isInternal toggle, assign/unassign validated against the ticket's own app, and status transition. Terminality is derived from supportTicketCategoryStatuses in the UPDATE - never a status list in code - so resolve/reopen are the same call with a different status and resolvedAt/resolvedBy stamp and clear accordingly. Authz is a correlated admin grant on the TICKET's own appKey, in-statement, zero rows IS the refusal. Since then the statements moved into lib/support-core.ts (ENAMEL-27) so the UI and the REST surface share ONE authorization definition; the gate is unchanged in substance. OPERATIONALLY INERT and this is not a caveat to bury: enamel has zero userGroups rows at appKey='enamel', so the queue is empty for every user and no one can reach a ticket. The surface is correct and unusable until grant #1 lands. Closing the build, not the usability.