Filament Invite Laravel Package

Getting Started

v2.0.2 is a compatibility patch: the only change is a widened laravel/framework (and by extension supporting dependency) constraint to allow installing on Laravel 13 (#26). There are no API, config, or migration changes versus v2.0.1, so if you are already on 2.x you can upgrade with a normal composer update concept7/filament-invite and re-run your test suite.

If you are picking the package up for the first time:

1. composer require concept7/filament-invite
2. Publish and run the migration: php artisan vendor:publish --tag="filament-invite-migrations" then php artisan migrate. Check database/migrations for the invitations table before assuming the tag name — vendor tags vary between releases.
3. Publish the config if you need to tune expiry/token behaviour: php artisan vendor:publish --tag="filament-invite-config".
4. Register the plugin on the panel you want invitations to live on, inside your PanelProvider::panel() chain — usually ->plugin(FilamentInvitePlugin::make()).
5. Add the package's trait / implement its contract on your User (or App\Models\User) model so invitees can be persisted and later accept.
6. Make sure the accepting user model still satisfies Filament's own requirements (FilamentUser with canAccessPanel()), otherwise the invitee lands on a panel they cannot enter.

First real use case: log into /admin, open the invitations resource, invite a teammate by email, and confirm they can complete registration from the signed link. That single loop exercises mail, token generation, and the accept route — if all three work, the rest of the package is configuration.

Where to look first when something is off: the published config (expiry, guard, redirect targets), the package's routes file (php artisan route:list --path=invite), and the notification class — the email is the thing most likely to be customised or swapped.

Implementation Patterns

Panel-scoped registration. Register the plugin only on the panels that should expose invitations. Multi-panel apps frequently want invites on an admin panel but not on a customer-facing panel; doing this per-provider keeps the resource and routes out of the panels that don't need them.

Role/tenant assignment on accept. The most common day-to-day extension is granting something at acceptance time. Listen for the package's accept event (or override the accept controller/action) and attach a role, set tenant_id, or assign a team. This keeps the invite resource generic while your app encodes its own onboarding rules.

Invite-then-approve workflows. Because invitations are persisted rows, they double as an audit trail. Query them directly to build "pending invites" widgets, resend flows, or cleanup jobs that purge expired rows on a schedule — cheaper than re-deriving state from mail logs.

Pairing with Filament's own user management. Filament v3/v4 panels typically already have a UserResource. Keep invitations as the creation path and the user resource as the editing path; avoid duplicating "create user" forms in both places or your validation rules will drift.

Testing. Use Notification::fake() and assert the invitation notification was sent, then pull the token from the persisted invitation record rather than parsing the email body. This keeps tests stable if you swap the notification's markdown view.

CI matrix. With the Laravel 13 constraint now allowed, add 13.* to your dependency matrix. If you support both Laravel 12 and 13, pin with "laravel/framework": "^12.0|^13.0" in your root composer and let the package float — Composer will resolve the matching package version per job.

Integration tip. If you customise the accept redirect, prefer config over editing vendor-published views; published views are the first thing to fall out of sync on the next minor release.

Gotchas and Tips

• The Laravel 13 bump is a floor/ceiling change, not a feature. If your app is on Laravel 11 or 12, nothing here changes for you. If you're testing against 13, verify Filament's own Laravel 13 support first — the plugin can allow the framework version while the panel package still cannot install.
• Watch transitive constraints. Composer may still refuse the update because filament/filament or another dependency caps the framework. Run composer why-not laravel/framework 13.* before filing a bug against this package.
• Migrations are publish-once. If a future release alters the invitations table, vendor:publish will silently skip the existing file. Diff the package's database/migrations directory against your database/migrations after minor upgrades.
• Expired invites are a silent failure mode. The accept route typically 403/404s on expiry with no helpful message. Log or surface a distinct "invitation expired" state, and give admins a resend action — it is the single most requested support ticket in invite-based onboarding.
• Duplicate invitations. Without a guard, inviting the same email twice creates two valid tokens. Decide on a policy (invalidate previous, or unique index on email + pending status) and enforce it in a form ->unique() rule or an observer.
• Mail configuration is the usual culprit. Local MAIL_MAILER=log means invites "work" but nobody receives anything; and queued notifications need a running worker. Check failed_jobs first when an invite is reported missing.
• Token handling. Treat invitation tokens as secrets: don't log the accept URL, and ensure the accept route is rate-limited. If you swap the token generator, keep it cryptographically random and hash at rest where practical.
• Extension points to prefer: the plugin's config file, the published notification class, and model events over editing vendor code. Vendor edits are lost on composer update and will not survive the next compatibility bump like this one.
• Debugging accept failures: php artisan route:list --path=invite to confirm the route exists on the right panel, then verify APP_URL — signed URLs generated under the wrong host fail validation with a generic 403 that looks like a token problem.