- What is jeffersongoncalves/servicedeskkitv4?
- ServiceDeskKit v4 is a Laravel and Filament starter kit for building service desk and helpdesk applications. It provides a foundation for support workflows, service requests, and ticket management rather than being a general-purpose library. It is described as targeting Laravel 13.x and Filament 4.x, so it is an opinionated application scaffold. Teams already standardized on Laravel plus Filament v4 are the intended audience.
- What are the requirements for installing servicedeskkitv4?
- The package is documented as a Laravel 13.x and Filament 4.x starter kit, so you should expect to run Filament v4 with Livewire 3 on a current PHP version. The release notes evaluate PHPStan against PHP 8.4, which suggests the maintainer intends to track current PHP releases. The supplied notes do not enumerate exact composer constraints, so check composer.json for the authoritative Laravel, PHP, and Filament floors before installing. If your application runs Laravel 11 or 12, confirm support in the package metadata first rather than assuming it.
- Does servicedeskkitv4 work with Filament v3 or Livewire/Inertia setups?
- No. This is a Filament v4 application kit, and teams on Livewire, Inertia, or Nova have no viable path without substantial rework. Filament v3 users would need to migrate to v4 upstream before adopting the kit. The architecture fit is deliberately narrow because the kit ships panel scaffolding and resources tied to Filament v4 conventions.
- Is version 4.14.0 a breaking change from 4.13.x?
- Very likely, even though it is framed as a feature. Release 4.14.0 includes PR #63, which moves the User and Admin models, resources, and login into separate packages, and that relocates authentication, authorization surface, and the primary Filament panel scaffolding. Anyone who has published or extended those assets should treat 4.13.x to 4.14.0 as a major-version upgrade until confirmed otherwise. The supplied release notes contain PR titles only, with no changelog entry, upgrade guide, or deprecation path for that change.
- How do I migrate from 4.13.4 to 4.14.0?
- Read the diff rather than the release notes. Run git diff 4.13.4..4.14.0 against composer.json, the config directory, and the service provider to identify constraint changes and namespace moves. Before upgrading, grep your codebase for published vendor assets, extended User or Admin models, custom Filament resources that extend package base classes, and any auth overrides. Those are the areas most likely to need remapping because of the user and admin package extraction.
- What are the new user and admin packages in 4.14.0?
- The release notes only describe PR #63 as using user and admin packages for models, resources, and login, and do not name them. What is clear is that adopting 4.14.0 adds one or more additional first-party dependencies, each with its own release cadence and PHP and Filament constraints. Verify the exact package names and their declared constraints from composer.json and the lock file before committing. Those transitive constraints may narrow your supported Laravel and PHP matrix.
- Can I still customize the User and Admin models and the login page?
- Customization should still be possible, but the extension points move. Anything that extends, resolves, or publishes the package's User or Admin models, login page, or panel provider likely needs a namespace remap to the new packages. Check whether the original App\Models\User and admin resources are retained with shims or removed outright. The supplied data does not confirm a deprecation window, so plan for a hard cutover.
- Does the 4.14.0 auth change require a database migration?
- The notes do not say whether the change is a code move or also alters the underlying guard and provider configuration, session handling, or password reset flows. If the new user package changes the auth provider model or table, a migration may be required. Inspect the config and service provider diff for guard, provider, and password broker settings before running the upgrade. Treat the change as code-only until you have confirmed it in the diff.
- Is servicedeskkitv4 production ready and actively maintained?
- The evidence is mixed and should be treated as provisional. CI standardization, dependabot automation, and PHPStan runs against PHP 8.4 are positive maintenance signals, but all non-bot commits come from a single maintainer, which is a real bus-factor concern. The supplied data contains no composer download figures, issue history, or test matrix output, so absence of contradicting evidence is not evidence of stability. Pin versions and review changes before relying on it in production.
- How is the CI and testing set up, and does the package version track Filament?
- Version 4.14.0 shipped alongside a Filament bump to v4.14.0, and the package's version number moves in lockstep with Filament's, which suggests its release cadence is coupled to that upstream line. CI includes standardized changelog, dependabot, and test workflows, with PHPStan running against PHP 8.4. Whether those PHP 8.4 and static analysis jobs actually gate merges, and which Laravel versions are in the real CI matrix, is not stated in the supplied data. Confirm the composer Filament constraint is a range such as ^4.0 rather than a pin like ^4.14 to understand the blast radius of the next Filament patch.