Ticketing has no notification integration (no ticketing.* category, no Notifications class) #8

New Issue

jwed · 2026-07-27T18:04:16-07:00

jwed commented

2026-07-27 18:04:16 -07:00

Persona: superadmin@playwright.test
URL: https://central-dev.vancs.org/app/ticketing (and /app/notifications/log)

What I did:

Created a Help Desk group ("QA Sweep Group", prefix QAS) at /app/ticketing/settings.
Created a ticket (QAS-0001) via /app/ticketing/create as the submitter.
Sent a reply on the ticket ("Reply to submitter") as the agent.
Checked /app/notifications/log (the shell's shared Notification Log) for any resulting entry.

Expected: Comparable snap-ins all fire an email/SMS notification through the shared
notification system for equivalent events — e.g. forms.assigned, forms.submitted,
tasks.assigned, oncall.job_assigned, oncall.job_offered, staff_employment.noe_posted.
I'd expect ticketing to notify the submitter when their ticket gets a reply, and/or notify an
assigned agent when a ticket is assigned to them.

Actual:

No new entry appeared in the Notification Log after creating the ticket or sending the reply.
The Log's "Category" filter dropdown lists categories for every other app (account.security,
admissions., attendance.confirm_request, bosch., forms., inbox., inventory.collection_email,
oncall., payments.receipt, signage., staff_employment.noe_posted, system., tasks.,
tools.file_downloaded, verification.requested) but no ticketing.* category exists at all.
Confirmed in source (dashboard-ticketing repo, via Gitea contents API): src/ has no
Notifications directory (every other snap-in that participates in the shared notification
system has one), and TicketingServiceProvider.php contains no mention of notif anywhere.
The ticket's own Automation settings tab only has an "auto-close resolved tickets after N days"
option — nothing notification-related there either.

So it looks like ticketing currently has zero integration with the shell's notification system:
submitters and agents have no way to learn about ticket activity except by manually checking the
queue/My Tickets page.

Console errors: none — this is a missing-feature/integration-gap finding, not a crash.

Filed as an integration gap under the "new/existing feature should surface in shell notifications"
category from this run's test plan, since every comparable snap-in (forms/tasks/oncall/staff-employment)
does have this integration and ticketing doesn't.

Filed automatically by the Claude-driven QA sweep (/opt/qa-agent). The marker below dedupes repeat reports — do not edit it.

**Persona:** superadmin@playwright.test **URL:** https://central-dev.vancs.org/app/ticketing (and /app/notifications/log) **What I did:** 1. Created a Help Desk group ("QA Sweep Group", prefix QAS) at /app/ticketing/settings. 2. Created a ticket (QAS-0001) via /app/ticketing/create as the submitter. 3. Sent a reply on the ticket ("Reply to submitter") as the agent. 4. Checked /app/notifications/log (the shell's shared Notification Log) for any resulting entry. **Expected:** Comparable snap-ins all fire an email/SMS notification through the shared notification system for equivalent events — e.g. `forms.assigned`, `forms.submitted`, `tasks.assigned`, `oncall.job_assigned`, `oncall.job_offered`, `staff_employment.noe_posted`. I'd expect ticketing to notify the submitter when their ticket gets a reply, and/or notify an assigned agent when a ticket is assigned to them. **Actual:** - No new entry appeared in the Notification Log after creating the ticket or sending the reply. - The Log's "Category" filter dropdown lists categories for every other app (account.security, admissions.*, attendance.confirm_request, bosch.*, forms.*, inbox.*, inventory.collection_email, oncall.*, payments.receipt, signage.*, staff_employment.noe_posted, system.*, tasks.*, tools.file_downloaded, verification.requested) but **no `ticketing.*` category exists at all**. - Confirmed in source (dashboard-ticketing repo, via Gitea contents API): `src/` has no `Notifications` directory (every other snap-in that participates in the shared notification system has one), and `TicketingServiceProvider.php` contains no mention of `notif` anywhere. - The ticket's own Automation settings tab only has an "auto-close resolved tickets after N days" option — nothing notification-related there either. So it looks like ticketing currently has zero integration with the shell's notification system: submitters and agents have no way to learn about ticket activity except by manually checking the queue/My Tickets page. **Console errors:** none — this is a missing-feature/integration-gap finding, not a crash. Filed as an integration gap under the "new/existing feature should surface in shell notifications" category from this run's test plan, since every comparable snap-in (forms/tasks/oncall/staff-employment) does have this integration and ticketing doesn't. --- _Filed automatically by the Claude-driven QA sweep (`/opt/qa-agent`). The marker below dedupes repeat reports — do not edit it._

jwed added the e2e-failure label 2026-07-27 18:04:16 -07:00

jwed commented

2026-07-28 06:03:13 -07:00

Still occurring — re-verified 2026-07-28 (full-sweep). Created a fresh ticket (QA-0001) and sent a reply as the agent; checked /app/notifications/log afterward and there's still no ticketing.* category in the filter, and no log entry generated for either the create or reply action.

Still occurring — re-verified 2026-07-28 (full-sweep). Created a fresh ticket (QA-0001) and sent a reply as the agent; checked `/app/notifications/log` afterward and there's still no `ticketing.*` category in the filter, and no log entry generated for either the create or reply action.

jwed referenced this issue from a commit

2026-07-28 09:58:27 -07:00

Ticketing joins the notification platform (closes #8)

jwed closed this issue

2026-07-28 09:58:27 -07:00

jwed commented

2026-07-28 09:58:41 -07:00

Fixed in 4719cba. Verified after the change: 2 ticketing.* categories register (39 total), so the Category filter now lists them.

Your source reading was right, and more literally than "not wired up": this was not a mail sweep like the other apps. There was no existing Mail:: call to redirect — TicketMessageController::notifySubmitter() was an empty stub:

// Placeholder for email notification
// In production: Mail::to($submitterEmail)->send(new TicketReplyMail(…));

So nobody has ever been told their ticket was answered.

Two categories, matching the moments somebody is waiting on another person — the two you suggested:

ticketing.replied → the submitter when an agent replies. Internal notes are excluded at the call site, since the point of an internal note is that the submitter does not see it.
ticketing.assigned → the agent a ticket is handed to. The previous assignee is captured before the write so a genuine hand-off is distinguishable from a save that merely touched other fields, and assigning to yourself sends nothing.

Neither is mandatory — a reply notice is a convenience rather than a security or financial record, so it is opt-out in preferences.

Bridge shape follows ToolsNotifier: one class owning the platform contact, available() false when the platform is absent or dark, and a queue failure logged rather than thrown, because sending a reply must succeed even if the email cannot be queued.

One consequence worth stating plainly: Notifications is still beta and ships dark, so with the platform disabled ticketing stays silent, exactly as it is today. There is no direct-mail fallback here, unlike the swept apps, because there was never any direct mail to fall back to. These start delivering when Notifications is enabled.

Fixed in 4719cba. Verified after the change: 2 `ticketing.*` categories register (39 total), so the Category filter now lists them. Your source reading was right, and more literally than "not wired up": this was **not** a mail sweep like the other apps. There was no existing `Mail::` call to redirect — `TicketMessageController::notifySubmitter()` was an empty stub: ```php // Placeholder for email notification // In production: Mail::to($submitterEmail)->send(new TicketReplyMail(…)); ``` So nobody has ever been told their ticket was answered. Two categories, matching the moments somebody is waiting on another person — the two you suggested: - **`ticketing.replied`** → the submitter when an agent replies. Internal notes are excluded at the call site, since the point of an internal note is that the submitter does not see it. - **`ticketing.assigned`** → the agent a ticket is handed to. The previous assignee is captured *before* the write so a genuine hand-off is distinguishable from a save that merely touched other fields, and assigning to yourself sends nothing. Neither is mandatory — a reply notice is a convenience rather than a security or financial record, so it is opt-out in preferences. Bridge shape follows `ToolsNotifier`: one class owning the platform contact, `available()` false when the platform is absent or dark, and a queue failure logged rather than thrown, because sending a reply must succeed even if the email cannot be queued. One consequence worth stating plainly: Notifications is still `beta` and ships dark, so **with the platform disabled ticketing stays silent, exactly as it is today**. There is no direct-mail fallback here, unlike the swept apps, because there was never any direct mail to fall back to. These start delivering when Notifications is enabled.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jwed/central-ticketing#8