Filament Right Click Laravel Package

Technical Evaluation

Architecture fit

• Pure presentation-layer enhancement: a Table macro (contextMenuActions(), contextMenuBulkActions()) plus an optional Board macro for Flowforge. No schema changes, no migrations, no data model coupling, no service-provider-heavy wiring beyond FilamentRightClickPlugin::make().
• Correctly avoids re-implementing action semantics. Every menu entry wraps a native Action/BulkAction, so modals, confirmation, authorization, validation, notifications, and redirects remain owned by Filament. This is the right architectural bet — the package adds an input surface, not a second action system.
• Additive and removable: unregistering the plugin and dropping the macro calls restores prior behavior with no cleanup debt. Low architectural lock-in.

Integration feasibility

• Install path is trivial (composer require, php artisan filament:assets, one plugin registration per panel). Menu definitions live beside existing table() config, so discovery cost for a Filament-fluent developer is near zero.
• Reusing existing actions means we can retrofit context menus onto mature tables without duplicating authorization logic — the main reason these retrofits normally stall.
• Feasible for any team already on Filament 5; blocked or deferred for panels still on Filament 4 (see compatibility below).

Technical risk

• Version coupling is the dominant risk. v2.0.0 requires Filament ≥5.6.4 and drops v4 entirely; v4 consumers must pin ^1.5. That is a hard fork in the support matrix and must be reconciled with our own Filament upgrade calendar before adoption.
• Reliance on non-public Filament internals. The package calls mountTableAction(actionName, recordKey), the newer unified mountAction(actionName, [], { recordKey }), and synchronizes Filament's selected-record properties before mounting bulk actions. These are not contractual APIs. A Filament minor release can break action firing without a PHP error — the menu renders, the click does nothing.
• Thin validation surface. 40 stars, 0 dependents, single maintainer, MIT. Effectively one production reference (the author). Bus factor and regression coverage are the real costs, not the license.
• Accessibility gap. Keyboard support is genuinely good (ContextMenu key, Shift+F10, arrows, Enter/Space, Escape), but touch/long-press is explicitly out of scope for v1. A right-click-only affordance is undiscoverable for mouse-less users and invisible on tablets.
• Deployable asset step. php artisan filament:assets becomes part of the release runbook; the assets are loadedOnRequest(), so a missed step yields silently dead menus.
• Silent-failure UX. An action that is hidden/disabled/unauthorized for a row causes the menu to close with no feedback. Server-side enforcement is correct, but from the user's chair it is indistinguishable from a bug. v2's ContextMenuItem::mirrors('rowAction') (per-row hiding, dangling separators/sections pruned) is the mitigation — and a reason to prefer v2 where possible.

Key questions

1. What Filament version(s) are our panels on today, and what is the upgrade cadence? That single answer determines 1.5.x vs 2.x and whether adoption is now or later.
2. Do we need tablet/touch parity for the affected admin surfaces, or is this desktop-only back-office tooling?
3. Do we publish/bundle Filament assets through a custom Vite pipeline? If yes, we inherit the DOM contract (data-filament-right-click-record-config, row wire:key, data-card-id) and its drift risk.
4. Is Flowforge actually in production for us, or is Kanban support speculative scope we should ignore at evaluation time?
5. What is our tolerance for pinning a package that tracks Filament minors faster than we do — and do we have a canary test that would catch a broken mount path?
6. Who owns the internal style guide deciding which actions belong in a context menu versus the row action column?

Integration Approach

Stack fit

• Fits a Laravel + Filament admin codebase with no new infrastructure, no queue/worker implications, no external service dependency. It is a UI affordance on top of an existing action registry.
• Best fit where row action columns are already crowded or where destructive/secondary operations are buried in a "more" dropdown — that is where context menus convert directly into reduced click depth.
• Poor fit for public-facing or touch-primary interfaces.

Migration path

• No data migration. Adoption is opt-in per table; rollback is deleting the macro calls and the plugin registration.
• Version migration is the only real migration: 1.x → 2.x is gated on Filament ≥5.6.4. Sequence it with the Filament upgrade, never ahead of it — do not adopt v2 on a panel that is still on v4.
• Start on the line that matches our current Filament version, and treat the Filament upgrade as the trigger to move lines.

Compatibility

• Flowforge support auto-registers only when Relaticle\Flowforge\Board exists — zero cost if we don't use it, no conditional code from us.
• Coexistence with other table plugins and custom Filament themes needs a smoke test, not a deep audit; the package does not patch Filament's rendering, it suppresses the browser context menu only on tables that opt in.
• Bulk menu reuses Filament's own selection state including select-all-across-pages, so behavior stays consistent with the existing bulk dropdown instead of creating a parallel selection model.

Sequencing

1. Confirm Filament version per panel; choose 1.5.x or 2.x accordingly and pin the minor.
2. Install and register the plugin on one non-critical panel only.
3. Convert 2–3 representative tables deliberately chosen for coverage: one destructive action, one bulk action, one table with policy-driven hidden()/disabled() actions.
4. Verify authorization by logging in as a low-privilege role and confirming the menu closes rather than executing — this is the assertion that matters most.
5. Add Flowforge card menus only if Flowforge is already shipped to users.
6. Write the internal pattern into our Filament standards doc (ordering, destructive last, confirmations required, no duplication of the row action column) before any broader rollout.
7. Expand table by table; keep the first converted table as the upgrade canary.

Operational Impact

Maintenance

• Single-maintainer OSS with effectively no downstream dependents. Assume we may need to patch or fork, and budget a small ongoing cost for that possibility rather than a support contract.
• Filament minor upgrades now require a targeted regression check of the context-menu mount path on the canary table. Cheap if it's in the upgrade checklist; expensive if it's discovered in production.
• Code volume we own is small (menu definitions), so internal maintenance load is low — the exposure is external, not internal.

Support

• No vendor SLA; GitHub issues only. Support burden will be internal: developers will ask "why isn't the menu item firing" and the answer will usually be "the action is hidden for that record" — document that first.
• The ContextMenuItem DSL needs a short internal reference so developers extend existing menus rather than hand-rolling parallel implementations.

Scaling

• Runtime cost is negligible: menu configuration is static metadata, assets load on request only for tables that opt in, and every click is a normal Livewire round-trip through Filament's existing action path. No additional queries, no new background work.
• Bulk operations inherit Filament's selection semantics, so they stay inside the performance envelope we already accept for the bulk dropdown.
• The real scaling limit is cognitive: unbounded menu growth per table degrades the very UX the package exists to improve. Cap menu length by convention.

Failure modes

• Silent mount breakage after a Filament minor bump — menu opens, action never fires, no error. Highest-probability, highest-impact; requires the canary test.
• Missing asset publish (filament:assets skipped in a deploy) — menus never open, again with no error signal.
• Authorization dead-ends — item visible, click produces nothing because the action is hidden/disabled for that row. Mitigated by adopting v2's mirrors(); otherwise it reads as a defect.
• Custom bundle drift — if we self-bundle assets, the documented DOM contract becomes our liability and can silently desynchronize.
• Touch/mouse-less users lose the feature entirely; keyboard users must know Shift+F10, which most won't discover without a hint.
• Heavy closures in menu definitions evaluated per render can quietly add cost on large tables.

Ramp-up

• Low. Roughly half a day for an experienced Filament developer: the DSL is a thin layer over familiar Action::make() usage and the README covers single, bulk, submenu, and Flowforge cases with working examples.
• The genuine ramp-up is editorial, not technical: deciding what belongs in a context menu versus the row action column, and enforcing consistent ordering and destructive-action placement across tables.
• Recommended posture: pilot, don't standardize yet — adopt on one panel, pin the version, put the mount-path canary in the upgrade checklist, and revisit a broader rollout after one Filament upgrade cycle proves the coupling holds.