- How do I install jeffersongoncalves/servicedeskkitv5 in a Laravel application?
- Install it with Composer and then publish the package's config, migrations, and Filament assets so the service desk resources register in your panel. Because version 5.9.0 delegates User and Admin models, Filament resources, and login to external packages, install it in a scratch branch first and confirm those dependencies resolve alongside your existing Filament version. Run the migrations and check that the panel provider and auth guard wiring match what the package expects before merging.
- Is upgrading from 5.8.x to 5.9.0 a breaking change?
- In practice yes. PR #98 moves the User and Admin models, Filament resources, and the login flow out of the package and onto external user and admin packages, which changes published classes and auth wiring even though 5.9.0 is only a minor version bump. No UPGRADING.md or migration note is referenced, so treat it as a breaking change and pin 5.8.4 until you have diffed the published files. Stand up a branch, install 5.9.0 in a clean environment, and compare config, migrations, models, resources, and panel registration against 5.8.4.
- Which user and admin packages does ServiceDeskKit v5.9.0 now depend on?
- The release notes describe switching to external user and admin packages for models, resources, and login, but the exact package names and version constraints need to be confirmed from the composer.json and documentation. This is one of the open questions flagged in the technical assessment. Check whether those packages are maintained by the same author, what their release cadence looks like, and whether they collide with anything your app already pins.
- Does the package still ship migrations for users and admins, or do I own that schema?
- That is not clearly stated in the release notes, and it is one of the biggest practical risks of the 5.9.0 change. If user and admin tables move ownership to external packages, your published migrations and existing data need an explicit schema review rather than a silent composer update. Compare the published migration set from 5.8.4 and 5.9.0 side by side before touching production data.
- Which Laravel and Filament versions does this service desk kit support?
- The package targets Laravel 13.x and Filament 5.x, and its CI runs PHPStan on PHP 8.4. What is not established is a full tested compatibility matrix, so do not assume Laravel 11 or 12 support just because the code may run there. Verify your Filament version and panel providers against 5.9.0 before committing, and confirm whether 5.9.0 is a supported floor, a ceiling, or a pinned requirement.
- Can I use this package if my app already has its own User model and authentication?
- Potentially yes, and the 5.9.0 direction may actually align better with apps that already own auth, since the package now delegates models and login rather than owning them. The trade-off is that panel registration, guard configuration, and Filament resource namespaces become cross-package concerns you have to reconcile yourself. If you have heavily customized the package's old User or Admin models, expect more work, not less.
- How do I customize the ticket, request, and conversation models and Filament resources?
- Publish the package's config, migrations, and models into your application, then extend the ticket and conversation models and adjust the Filament resources in your own panel provider. In 5.9.0 the resource namespaces and model ownership moved, so any overrides written against 5.8.x need to be re-pointed at the new classes. Keep customization in your app rather than editing vendor files so future upgrades stay reviewable.
- Is this package production-ready, and how actively is it maintained?
- It is a single-maintainer package with a very high ratio of CI and dependabot churn to functional change, which makes the changelog low-signal and increases the chance meaningful changes are buried. That does not make it unusable, but it argues for pinning exact versions, reading release diffs, and monitoring the repository before relying on it in a production help desk. Static analysis passing on PHP 8.4 is a good signal for code cleanliness but says nothing about behavioral compatibility with your app.
- How does this compare to building ticketing and help desk features directly in Filament?
- This kit is best understood as a starter kit and composition layer over Laravel and Filament rather than a self-contained module, which is a meaningful architectural commitment. If you want full control over the ticket schema, auth, and resource layout, building the models and Filament resources yourself avoids both the multi-package dependency graph and the maintainer risk. If you want a head start on tickets, requests, and customer conversations, evaluate the 5.9.0 layout against your own auth setup before adopting.
- How should I test a service desk workflow before deploying an upgrade?
- Set up a scratch Laravel and Filament environment, install 5.9.0 there, and diff the published config, migrations, models, resources, and auth wiring against 5.8.4. Then walk the critical paths in feature tests: login and guard behavior, ticket creation, request handling, and conversation threading, using a fresh database to catch migration ownership problems. Only after those pass should you apply the same diff to your real application.