Ticket Notification Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on ticketing notifications. This is a glue package, not a platform. It answers a narrow question: "do we wire up ticket-created / ticket-modified emails ourselves, or use an existing bundle?" At 1 star, 0 dependents, and a score of ~1.9, the answer is almost always "write the ~150 lines yourself."
• Roadmap scoping for internal support tooling. The feature surface is intentionally thin: email only, on create and on modify, no recipient preferences, no digests, no escalation/SLA timers, no threading. If your roadmap needs any of those, this package establishes the floor of the problem, not the ceiling.
• Stack-fit signal, with a correction. Despite being filed as a Laravel/PHP package, this is a Symfony bundle built specifically against HackzillaTicketingBundle. That mismatch is itself a decision input — if you're on Laravel, this is not an adoption candidate at all; it's a design reference.
• Categorizing ticketing notifications as table stakes. The existence of a one-star, zero-dependent package doing exactly this suggests "email on ticket change" is commodity functionality. Do not resource it as a differentiator; resource it as a half-day task.
• Vendor/tech-debt exposure assessment. Adopting it means taking on two coupled, low-traffic dependencies (this bundle and Hackzilla's) whose combined maintenance you don't control. MIT license means forking is cheap — which lowers risk but also lowers the value of depending on it.
• Use cases it genuinely fits: small internal helpdesk, low ticket volume, Symfony shop already standardized on Hackzilla, a single shared inbox as the notification target.

When to Consider This Package

Consider it when all of these are true:

• You are on Symfony and already running HackzillaTicketingBundle in production.
• You need only "email someone when a ticket is created or updated" — nothing more.
• Volume is low and internal-facing; missed or duplicated emails are tolerable.
• Your team is comfortable owning a fork (MIT) or vendoring the code, and can read a small event-subscriber implementation in an afternoon.
• You want a working reference for how to subscribe to Hackzilla's ticket events before writing your own.

Look elsewhere when:

• You're on Laravel — the package won't drop in. Port the pattern into a queued Notification + model observer instead; expect roughly half a day.
• You need delivery guarantees, retries, digesting, per-user preferences, Slack/webhook fan-out, or escalation — none of that exists here.
• You are not already on Hackzilla. Pulling in two interdependent, low-adoption bundles to get email notifications is a worse trade than owning the code.
• You're customer-facing or under audit/compliance requirements; email-only with no audit trail or templating controls won't satisfy that.
• You want a support system, not a notification add-on. Evaluate Chatwoot, Zendesk, or Freshdesk at the product level and use their native notifications.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed micro-add-on that sends email when a support ticket is created or changed. It carries no licensing or procurement cost, but also essentially no adoption — one star, no downstream projects. Treat it as a reference implementation, not a dependency. The real decision it informs is that ticket notifications are commodity functionality: a small, one-time engineering task rather than a buy-vs-build program. Recommend we not adopt it and not budget for it.

For engineering: It's a thin Symfony event subscriber binding Hackzilla's ticket events to the mailer. Two caveats that decide this: it's Symfony-only (not Laravel, despite how it's catalogued), and it hard-couples to HackzillaTicketingBundle. Recommended approach: spend 15 minutes reading its source, then implement the equivalent in our own stack — queued notifications, a preferences table, and a transport we control. Half a day of work, no maintenance tail, no third-party coupling. If we're already on Hackzilla and only need create/modify emails, flipping it on is a legitimate shortcut — but plan to fork it, because we will end up owning it.