Weave Code
Tickets For Laravel Laravel Package
roundly-consulting/tickets-for-laravel
A Laravel package that adds ticketing support to your application, providing models, migrations, and helpers for creating, tracking, and managing support tickets out of the box. Integrates with Eloquent and Blade views for quick setup and customization.
Tickets for Laravel is a lightweight ticketing package that adds a support-desk workflow to your Laravel application. It provides ready-made models, migrations, and relationships for creating tickets, tracking conversations, and managing the ticket lifecycle without building the foundation from scratch.
- Create and manage support tickets with subjects, descriptions, and metadata
- Organize tickets by status, priority, and assigned agent
- Add threaded replies/comments for back-and-forth communication
- Laravel-native Eloquent models, migrations, and configuration
- Extensible structure for custom fields, policies, and notifications
Frequently asked questions about Tickets For Laravel
- How do I install Tickets for Laravel?
- Require the package with Composer using roundly-consulting/tickets-for-laravel, then run the tickets:install Artisan command to publish and run the migrations and configuration. Run tickets:doctor afterwards to check your lifecycle and setup for warnings. Follow the prompts to publish any assets or config you intend to customize.
- Which Laravel and PHP versions are supported?
- The supported Laravel and PHP constraints are declared in the package composer.json, so check those against your application before installing or upgrading. The package is Laravel-native and relies on standard features such as service providers, policies, gates and migrations. Confirm compatibility on Packagist for the specific release you plan to use, especially before a major Laravel upgrade.
- Do I need to modify my User model to use this package?
- Yes. Your host User model must implement Contracts\Assignee using the Concerns\IsTicketAssignee trait, otherwise claim() and assign() fail at runtime with InvalidAssigneeException. The documented is_support flag is illustrative only, so map it to whatever agent flag your application already uses. Treat this as an identity and authorization integration, not just a package install.
- Is it a full helpdesk UI or a headless package?
- It is a headless ticketing core: models, migrations, routes, policies, lifecycle configuration, custom fields, guest links and activity logging. It does not ship a full SaaS-style helpdesk front end, so you build your own Blade, Inertia, Livewire or API layer on top of the provided domain model. Plan for UI, notification and reporting work in the host application.
- How secure are the guest requester links?
- Guest requesters receive guest link tokens, and the testing fake exposes assertGuestLinkIssued so you can verify issuance in tests. Treat these tokens as bearer credentials and review token expiry, revocation, scope and rate limiting in your integration, since those are host responsibilities. Do not expose guest endpoints publicly without throttling and validation in your application.
- Can I customize ticket statuses and the ticket lifecycle?
- Yes, statuses are swappable and the lifecycle is configurable. tickets:doctor accepts the shipped lifecycle's ambiguous resolved to closed path but warns on custom lifecycles, so review those warnings. When transitioning a resolved ticket, do it by status name rather than by status object, which can throw.
- How do custom fields work and will they scale?
- Custom fields support requester-editable values and can be used in filters, including datetime bounds. The package stores these values relationally, so plan an index strategy for the custom-field filters you expect to use in production. If you anticipate high ticket volume, benchmark filtered queries and exports before launch rather than after.
- How do I test tickets in my application?
- Use Tickets::fake() to swap the package in your test suite, and assertGuestLinkIssued to verify guest link behavior. Write standard Laravel HTTP and policy tests around ticket creation, assignment, lifecycle transitions and filtering. Pay special attention to tests that rely on @can('update', $ticket) and to date-range filters, since those behaviors are sensitive to patch releases.
- What changed in 1.0.1 and should I regression test before upgrading?
- There are no stated breaking API changes, but several behavioral fixes are worth regression testing. TicketPolicy::update() called without attributes can now allow a requester when requester_can_edit is off but an active requester_editable field exists. Date-only upper bounds for filter[created_to], filter[due_to] and datetime custom fields now include the whole named day, link deletion order is corrected, and guest-conversion watch ownership changed, so re-run policy, report, export and conversion tests.
- Does it support multi-tenancy, notifications or SLA automation out of the box?
- Not as first-class features. The package provides the ticketing domain core, while multi-tenant or per-team agent scoping, notifications and SLA automation are host-owned and typically built with policies, global scopes, events and queued jobs. If strict tenant isolation or complex SLA rules are hard requirements, validate the approach before committing to the package.
Weaver
How can I help you explore Laravel packages today?