- How do I install coringawc/filament-single-record-resource?
- Install it with Composer by running composer require coringawc/filament-single-record-resource in your Laravel project. There are no migrations, published assets, or config files to deal with, so installation is a single command. Once installed, you opt in per resource by adding the traits to your Resource and page classes.
- What problem does the single-record resource pattern solve in Filament?
- Filament resources are built around an index list of many records, which is awkward when a user only ever has one meaningful record, such as My Profile, My Wallet, My Settings, or Current Subscription. This package lets a resource always resolve to a single business record per authenticated user and redirects index and sidebar navigation to the view page. The result is a resource that behaves like a page without giving up Filament's resource conventions for forms, authorization, and breadcrumbs.
- Which Filament and Laravel versions are supported?
- The package declares support for Filament ^4.0 || ^5.0, and Laravel compatibility follows whatever versions your chosen Filament major supports. Because the plugin hooks into Filament page lifecycle seams that are not guaranteed across majors, you should pin both the package and your Filament major in the same constraint set. Avoid letting composer update float either one independently.
- How do I actually build a My Profile resource with it?
- Add the HasSingleRecordResource trait to your Resource class and the HasSingleRecord trait to the ViewRecord and EditRecord page classes, then drop the index page from the resource. Optionally implement the SingleRecordResolvableResource contract if you want first-class static-analysis support. The integration cost is a handful of use statements per resource, so it is cheap to try and equally cheap to remove.
- How does the package resolve which record to show, and can I customize it?
- By default the record is resolved with whereBelongsTo(Filament::auth()->user()), which works out of the box for a conventional belongsTo(User) relation. If you need more, resolveSingleRecordBuilder() lets you add constraints, and resolveSingleRecord() lets you take full control for firstOrCreate or tenant-aware logic. You can also override resolution on individual pages when one page genuinely differs from the rest.
- Does this package change how authorization works for these resources?
- Yes, and this is the biggest thing to understand before adopting it. As of v1.0.4, a resource remains accessible when viewAny() is denied but view() is allowed on the resolved single record, which is the correct behavior for a single-record resource but a deliberate deviation from Filament's default. Reviewers who do not read the changelog will assume viewAny() is still the gate, so document this for your team. Combined with a permissive custom resolver, it is a plausible path to unintended record exposure.
- Can I use nested child resources, like My Wallet to Companies to Products?
- Arbitrarily nested child resources are supported, and the resource trait helps nested resources resolve root URLs and slugs in single-record chains. However, query scoping across those chains is explicitly not enforced by the package, and the README pushes that responsibility onto the adopting team. You must scope each nested query yourself so a user cannot reach another user's records by manipulating route parameters.
- What happens when no record can be resolved, for example a user with no wallet yet?
- The README and release notes do not clearly document runtime behavior when the resolver returns null, so it is unclear whether you get a 404, a redirect, a blank page, or an exception. Treat this as a spike: create a user with no matching record and confirm the behavior before shipping. Multi-guard panels, multi-tenancy, and impersonation are similarly worth testing, since Filament::auth() may resolve differently than a tenant-scoped user.
- Is this package mature enough for production?
- Be cautious: it has around 12 GitHub stars, zero dependents, a single maintainer, and five releases in a short window, with no evidence of production usage outside the author's own workbench. The CI story is better than most packages at that star count, including Pest, PHPStan, Pint, and a matrix across Filament 4 and 5, but CI is not field usage. Pin the package to ^1.1 with a committed lockfile and expect to verify behavior yourself.
- Can I adopt it alongside my existing CRUD resources, and should I retrofit old ones?
- Yes, it coexists cleanly, because the traits are opt-in and scoped to individual Resource classes, so you can run the single-record pattern next to conventional index-based CRUD resources indefinitely. Do not retrofit existing index-based resources; the sequencing advantage here is adopting per resource. Start with a read-only root page such as My Profile or Current Subscription that has no nested children, then expand once the authorization and resolution behavior is confirmed.