Hermes 284313f908
Some checks are pending
Bidi Control Character Guard / bidi-control-guard (push) Waiting to run
Circular Dependency Check / Check for new circular dependencies (push) Waiting to run
Citus Migration Smoke / Combined migrations on single-node Citus (push) Waiting to run
E2E Fresh Install Tests / fresh-install-e2e (push) Waiting to run
ext-v2 guardrails / Run ext-v2 guard and ESLint (push) Waiting to run
Integration Tests / Check for relevant changes (push) Waiting to run
Integration Tests / ${{ (github.event_name == 'schedule' || github.event.inputs.suite == 'full') && 'Full integration suite' || 'Tier-1 integration subset' }} (push) Blocked by required conditions
Mobile checks / Mobile lint + typecheck (push) Waiting to run
Mobile checks / Mobile unit tests (push) Waiting to run
Mobile checks / Mobile dependency audit (report) (push) Waiting to run
Mobile checks / Mobile reproducibility checks (push) Waiting to run
Secrets guard (env backups) / Ensure no tracked env backup files (push) Waiting to run
Temporal Readiness / fast-readiness (push) Waiting to run
Temporal Readiness / docker-parity (push) Waiting to run
TypeScript Type Check / Nx affected typecheck (push) Waiting to run
Unit Tests / Skipped-test budget (push) Waiting to run
Unit Tests / Nx affected unit tests (push) Waiting to run
Unit Tests / Server unit coverage (informational) (push) Waiting to run
Validate Tenant Management Schema / Check for relevant changes (push) Waiting to run
Validate Tenant Management Schema / Validate Tenant Management Schema (push) Blocked by required conditions
EE Workflows Build Guard / ee-workflows-build-guard (push) Waiting to run
Initial import of AlgaPSA codebase from PSA server
Excluded: .git, node_modules, secrets/, compose.env, assemblyscript tgz

Source: /opt/alga-psa on psa.joliet.tech
2026-06-22 16:12:17 -05:00

4.3 KiB

Scratchpad — Ticket Response State Tracking

  • Plan slug: ticket-response-state-tracking
  • Created: 2026-01-04

What This Is

Keep a lightweight, continuously-updated log of discoveries and decisions made while implementing this plan.

Decisions

  • (2026-01-04) Data model: Use separate response_state field on tickets (not status metadata). Rationale: "who needs to respond" is orthogonal to "workflow stage" - encoding both in status would cause proliferation.
  • (2026-01-04) Update behavior: Automatic updates on comment creation based on author_type. No opt-in checkbox needed.
  • (2026-01-04) Client visibility: Response state visible to clients in client portal with friendly wording ("Awaiting Your Response" / "Awaiting Support Response").
  • (2026-01-04) UI display: Badge on status pill + new filter dropdown. No separate column.
  • (2026-01-04) Manual override: Staff can manually set response state via dropdown/button on ticket detail view.
  • (2026-01-04) On close behavior: Clear response_state to null when ticket is closed.
  • (2026-01-04) Workflow integration: Add TICKET_RESPONSE_STATE_CHANGED event for Automation Hub triggers.

Discoveries / Constraints

  • (2026-01-04) Status system: Statuses table has is_closed boolean but no other behavioral flags. Statuses are tenant-configurable with name, color, icon, order_number, is_default.
  • (2026-01-04) Comment author tracking: Comments already have author_type enum ('internal' | 'client' | 'unknown') and is_internal boolean. This gives us the data needed to infer response direction.
  • (2026-01-04) Event system: TICKET_COMMENT_ADDED event fires on comment creation with tenantId, ticketId, userId, and comment object (includes isInternal). Does NOT currently include author_type in payload - needs enhancement.
  • (2026-01-04) Workflow triggers: Existing WorkflowTriggerModel infrastructure supports event-based automation. Can register new event type.
  • (2026-01-04) Multi-tenancy: All tables use (tenant, entity_id) composite keys. Response state field and events must respect tenant isolation.

Key File Paths

  • Ticket model: server/src/interfaces/ticket.interfaces.tsx
  • Status interface: server/src/interfaces/status.interface.ts
  • Comment interface: server/src/interfaces/comment.interface.ts
  • Event definitions: server/src/lib/eventBus/events.ts
  • Ticket actions: server/src/lib/actions/ticket-actions/ticketActions.ts
  • Comment actions: server/src/lib/actions/commentActions.ts (likely location)
  • Initial schema: server/migrations/202409071803_initial_schema.cjs
  • Event catalog types: shared/workflow/types/eventCatalog.ts

Commands / Runbooks

  • (2026-01-04) Create migration: npm run migration:create -- --name add_response_state_to_tickets
  • (2026-01-04) Run migrations: npm run migrate

Implementation Order

  1. Database migration (F001-F003)
  2. Interface/type updates (F004)
  3. Backend logic for automatic updates (F005-F008)
  4. Event system integration (F031-F036, F039)
  5. Ticket detail view (F022-F025)
  6. Ticket list badges (F013-F016)
  7. Ticket list filter (F017-F021)
  8. Manual override UI (F009-F010, F023-F024)
  9. Close behavior (F011-F012)
  10. Client portal (F026-F030)
  11. Workflow/Automation Hub integration (F037-F038)
  12. Tenant isolation verification (F040)
  • User request: "Can comments, or actions?, on tickets trigger status updates? ... when we reply to the client, we could have the option to change the status to 'Awaiting Response from Client'"
  • Related: Automation Hub workflow system (docs/workflow/automation-hub-workflow-guide.md)
  • PRD: docs/plans/2026-01-04-ticket-response-state-tracking/PRD.md

Open Questions

  1. Should response state be a separate field or status metadata? Resolved: Separate field
  2. Automatic vs opt-in behavior? Resolved: Automatic by default
  3. Client portal visibility? Resolved: Visible to clients
  4. UI display approach? Resolved: Badge on status + filter
  5. Manual override capability? Resolved: Yes, via dropdown
  6. On close behavior? Resolved: Clear to null
  7. Workflow integration? Resolved: New event type
  8. Should the filter include time-based options (e.g., "Awaiting Client > 3 days")? → Deferred to future enhancement