- Is hackzilla/ticket-bundle a Laravel package?
- No. It is a Symfony bundle built on Doctrine ORM entities, Symfony DI service definitions, form types, validators, and Symfony Translator resources. There is no service provider, no Eloquent models, no Blade views, and no Laravel-facing API. Composer-installing it into a Laravel app still leaves you running Doctrine plus a Symfony container bridge, standing up a separate Symfony service, or rebuilding the model yourself.
- How do I install hackzilla/ticket-bundle?
- Install it with composer require hackzilla/ticket-bundle, then register the bundle in your Symfony kernel and make sure Doctrine entity mapping and the ticket schema are in place. You also need to wire the bundle routing (it now ships modernised, PHP-based routing config alongside the older XML style), security/access rules, and the Twig templates. Check the tagged 3.8.0 release notes and composer.json rather than assuming defaults, because the changelog is brief and the release followed a long gap.
- Does hackzilla/ticket-bundle support Symfony 6 or Symfony 7?
- Release 3.8.0 includes a commit that relaxes dependency constraints to allow some major versions, which may lift the Symfony ceiling. The changelog does not state which majors were widened, so the claim is unverified. Inspect composer.json and the CI matrix before committing: widening a constraint is not the same as testing against that version.
- How do I configure ticket statuses, priorities, and categories?
- Statuses, priorities, and categories are part of the bundle's ticket model and are configurable, which is the main reason to adopt it rather than write your own schema. Configuration lives in the bundle config plus the Doctrine entities, so check the shipped config reference for the exact keys in your installed version. Plan migrations carefully if you change the entity graph, since existing ticket rows reference those values.
- How do I connect tickets to my existing user table?
- The bundle integrates with existing user providers through its UserManager and UserLoad contracts. Version 3.8.0 added UserManager::findUserByUsername() and fixed a UserLoad::__construct() argument bug, so the user-provider bridge that was previously broken is now being repaired. You implement the manager against your own user source; note this fixes a Symfony contract, not a Laravel one.
- Does hackzilla/ticket-bundle send email notifications?
- Yes, optional email notifications are part of the feature set, alongside Doctrine-backed ticket storage. They are optional, so a default install will not mail anyone until you enable and configure them. Confirm the mailer wiring against your Symfony version, since transport configuration changed across Symfony releases.
- How are file attachments stored on tickets and replies?
- Tickets and replies both support file attachments, and the bundle persists them through its Doctrine entities. The overview does not spell out whether files land on the filesystem or in the database, so read the entity mapping and configuration in the installed version before sizing storage or planning backups. If you later extract the schema into another framework, the attachment table is the part that most often needs rework.
- Can I override the Twig templates to match my app's design?
- Yes. The bundle ships ready-to-theme Twig templates, and standard Symfony bundle template overriding lets you replace them without forking. Copy only the templates you actually change so future bundle updates stay easy to merge. If you are on Laravel, this is one of the pieces that does not transfer, since there is no Blade equivalent.
- Is hackzilla/ticket-bundle still maintained?
- Version 3.8.0 is the first release since February 2021, so treat it as evidence of a living maintainer rather than a support commitment. The release is largely housekeeping: constraint updates, removal of the friendsofsymfony/user-bundle suggestion, user-provider fixes, and routing and badge modernisation. Confirm the tag date yourself and keep an eye on release cadence before putting it on a critical path.
- What is the best way to use this bundle in a Laravel application?
- Extracting the schema and rebuilding on Eloquent is the realistic path; the entity graph for tickets, threaded replies, statuses, priorities, and attachments is stable and 3.8.0 does not change it. Running the bundle directly inside Laravel means Doctrine ORM plus a bridge, custom user mapping, replacing Symfony forms and validation, and extracting translations to lang/, which leaves roughly the whole Symfony surface in play. A sidecar Symfony service is technically feasible but turns a library choice into a platform choice: second runtime, second deploy pipeline, second auth boundary, and an internal API contract to maintain.