jeffersongoncalves/servicedeskkitv3
ServiceDeskKit v3 is a Laravel/PHP package for adding service desk and helpdesk features to your application, with ticket management, priorities, categories, and workflow scaffolding to speed up support tool development.
ServiceDeskKit v3 is a Filament plugin packaged as a Composer library — it ships Eloquent models, migrations, resources/pages/widgets, and a plugin class, but it is not an application skeleton. Day one you are integrating it into an existing Laravel + Filament app, not scaffolding a new one.
Minimal steps:
composer require jeffersongoncalves/servicedeskkitv3
php artisan vendor:publish --provider="JeffersonGoncalves\ServiceDeskKit\ServiceDeskKitServiceProvider"
# usually split: --tag=servicedeskkit-config / --tag=servicedeskkit-migrations
php artisan migrate
Then register it on exactly one panel in app/Providers/Filament/SupportPanelProvider.php:
public function panel(Panel $panel): Panel
{
return $panel
->id('support')
->path('support')
->plugin(ServiceDeskKitPlugin::make());
}
Finish with php artisan optimize:clear && php artisan filament:assets, log in, and confirm the ticket resource shows up in navigation.
Where to look first, in this order:
config/servicedeskkit.php (whatever it's actually named after publish) — table prefix, user/agent model binding, notification toggles. This is the highest-leverage file; most adaptation happens here, not in code.database/migrations/ in the vendor path — read the ticket/conversation schema before you run it. You need to know the FK targets and whether user_id points at your users table.src/ root — the plugin class and service provider, which is where resources, pages, widgets, and policies get registered. That file tells you the full surface area in about two minutes.First use case: stand up an internal support desk. Point the config's agent/requester model at your existing User, seed categories and priorities, and you have list → detail → reply → resolve working without writing a single Filament resource. That's the realistic 30–60 minute win, and it's the fastest way to decide whether the package's opinionated workflow fits your domain.
Pin the kit and Filament together. The package version mirrors the Filament minor it's built against — 3.3.55 bumps Filament to 3.3.55. Treat them as a co-dependency so composer update can't desync them:
"filament/filament": "~3.3.0",
"jeffersongoncalves/servicedeskkitv3": "~3.3.0"
Without this, a routine composer update can pull a kit release built for a Filament minor you don't run, and the failure mode is a class-not-found or a mysteriously blank page rather than a clean conflict.
Extend models and swap them via config — never edit vendor. Add tenant, department, SLA, or external-ticket-ID columns in your own dated migration, extend the package model, and rebind:
// config/servicedeskkit.php
'models' => [
'ticket' => App\Models\Ticket::class,
],
class Ticket extends \JeffersonGoncalves\ServiceDeskKit\Models\Ticket
{
protected $fillable = [/* ... + 'tenant_id', 'external_ref' */];
public function tenant(): BelongsTo { return $this->belongsTo(Tenant::class); }
}
This is the difference between a 20-minute upgrade and a two-day merge. Subclassing deep internals (resources, pages, actions) is the thing that makes upgrades expensive — prefer config bindings, then Filament hooks/custom actions, then package events, and only then subclassing.
Panel-scoped installation. Register the plugin only on the agent-facing panel. Registering it in a shared or customer panel leaks agent resources, widgets, and bulk actions to people who shouldn't see the queue — and Filament won't complain, it'll just render the navigation.
Authorization belongs in a policy, not in table queries. Map the ticket policy onto your role layer (Spatie or Filament Shield) so the two real rules live in one place:
public function view(User $user, Ticket $ticket): bool
{
return $user->hasRole('agent')
? ($ticket->assignee_id === $user->id || $user->hasPermissionTo('tickets.view-all'))
: $ticket->requester_id === $user->id;
}
Then enforce the list side with a global scope on your bound model rather than per-resource modifyQueryUsing. One scope, every table, every widget, consistent — filtering in the resource only covers that resource.
Multi-tenancy, done before seed data exists. Add tenant_id in an augmentation migration, apply a global scope, and add ->tenant() on the panel. Retrofitting tenancy onto a table with live tickets is a data-migration project; doing it on an empty table is ten minutes.
Fan out notifications from package events. Enable the kit's in-app Filament database notifications so agents get the bell icon for free, then add a thin listener for external channels and push it to a queue:
Event::listen(TicketCreated::class, SendTicketNotifications::class);
// listener implements ShouldQueue, dispatches mail + Slack
Keeping external channels in your listener (not in the package's config) means vendor upgrades can't change your notification semantics.
Custom Filament actions for the workflow gaps. Bulk assign, escalate priority, and "merge duplicate" are almost always the first asks that the kit doesn't ship. Implement them as Tables\Actions\BulkAction on the ticket table — that's a supported extension point and survives upgrades, unlike overriding the resource class.
Seed reference data in a seeder, not in the vendor migration. Categories, priorities, and statuses are data, not schema. A ServiceDeskSeeder you control lets you re-run and evolve them without touching published migrations.
Smoke-test every bump the same way: update the kit, re-publish config to a temp dir and diff it, migrate on a scratch DB, then click through three screens — ticket list, ticket detail, reply form. Those three screens cover nearly the entire package surface, and it takes five minutes.
compare/3.3.54...3.3.55 is only composer.lock and .github/workflows, deploy with confidence — no manual QA beyond the smoke test. Don't spend an afternoon on release notes that are pure noise.league/commonmark 2.8.3 → 2.9.0 and guzzlehttp/guzzle 7.15.0 → 7.15.1. If you render ticket bodies/comments as Markdown, re-verify sanitisation and any html_input settings after the commonmark bump — a minor version can change rendering of user-supplied content. If you use HTTP integrations, check timeout/redirect defaults.composer why-not / inspect the package's composer.json require block rather than trusting either. If your app is on Laravel 11, confirm the constraint actually permits it — this is a one-minute check that prevents an afternoon of runtime surprises.php artisan config:cache. If you cache first, the package falls back to hardcoded defaults and your model bindings silently don't apply. Symptom: tickets write to an unexpected table, or the agent relation returns null with no error.database/migrations with --force, future kit releases that add columns won't re-publish — you'll be stuck. Prefer keeping them as vendor-path anonymous-class migrations so they stay upgradeable, and put your alterations in your own later-dated migrations.Class not found after a bump almost always means a relocated class you referenced in a panel provider, config, or listener. After every minor: grep -r "ServiceDeskKit" app/ config/ and confirm those symbols still exist.php artisan filament:assets, plus a theme rebuild if you have a custom one — otherwise the ticket widgets and table render unstyled and you'll waste time on a CSS goose chase.discoverResources doesn't cover the path — Filament won't throw. Check the panel provider's discovery config first, then the plugin's register().php artisan tinker and hit the package model directly — Ticket::first() — before debugging Filament. If the model works and the UI doesn't, it's registration/authorization; if the model fails, it's config binding or migrations. That single step bisects the problem.How can I help you explore Laravel packages today?