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
Excluded: .git, node_modules, secrets/, compose.env, assemblyscript tgz Source: /opt/alga-psa on psa.joliet.tech
4.3 KiB
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_statefield 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_CHANGEDevent for Automation Hub triggers.
Discoveries / Constraints
- (2026-01-04) Status system: Statuses table has
is_closedboolean but no other behavioral flags. Statuses are tenant-configurable withname,color,icon,order_number,is_default. - (2026-01-04) Comment author tracking: Comments already have
author_typeenum ('internal' | 'client' | 'unknown') andis_internalboolean. This gives us the data needed to infer response direction. - (2026-01-04) Event system:
TICKET_COMMENT_ADDEDevent fires on comment creation withtenantId,ticketId,userId, and comment object (includesisInternal). Does NOT currently includeauthor_typein payload - needs enhancement. - (2026-01-04) Workflow triggers: Existing
WorkflowTriggerModelinfrastructure 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
- Database migration (F001-F003)
- Interface/type updates (F004)
- Backend logic for automatic updates (F005-F008)
- Event system integration (F031-F036, F039)
- Ticket detail view (F022-F025)
- Ticket list badges (F013-F016)
- Ticket list filter (F017-F021)
- Manual override UI (F009-F010, F023-F024)
- Close behavior (F011-F012)
- Client portal (F026-F030)
- Workflow/Automation Hub integration (F037-F038)
- Tenant isolation verification (F040)
Links / References
- 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
Should response state be a separate field or status metadata?Resolved: Separate fieldAutomatic vs opt-in behavior?Resolved: Automatic by defaultClient portal visibility?Resolved: Visible to clientsUI display approach?Resolved: Badge on status + filterManual override capability?Resolved: Yes, via dropdownOn close behavior?Resolved: Clear to nullWorkflow integration?Resolved: New event type- Should the filter include time-based options (e.g., "Awaiting Client > 3 days")? → Deferred to future enhancement