Filament Right Click Laravel Package

Product Decisions This Supports

• Reducing UI density in data-heavy admin screens. Teams accumulate row actions until the action column becomes a scrolling stack of icons. This package moves secondary and destructive actions out of the row into a context menu, keeping the visible action column for the 1–3 actions users actually perform most. Decision: do we invest in a table-layout/IA cleanup, or keep stacking icons?
• Power-user and operator workflows. Right-click is the native idiom for "operate on this record" in Linear, Jira, Notion, and every desktop file manager. If your users are internal ops staff, support agents, or engineers living in the panel for hours, this is a cheap perceived-quality and speed win. Decision: is our admin a high-frequency operator tool or a low-frequency CRUD form?
• Feature parity against a competitor or an incumbent internal tool. "We can't right-click a row" is a credible churn/complaint driver when migrating users off a tool that supported it. Decision: prioritize parity affordances vs. net-new capability.
• Bulk-operation discoverability. contextMenuBulkActions() respects Filament's existing selection, including select-all-across-pages, and falls back to the single-record menu when the row isn't selected. That's a real UX decision baked in — you get a defensible interaction model without specifying it yourself.
• Roadmap sequencing for workflow/automation surface area. Because menu items wrap any native Filament Action, this becomes a zero-glue delivery channel for new one-off actions — including the vendor's TriggerWorkflowAction. Decision: ship a new manual operation as a context menu entry instead of a new page, modal, or table action column entry.
• Build vs. buy. The menu chrome itself is a day or two of work; the durable value is the fragile parts: mounting through Filament's table action path, syncing Livewire selection state for bulk actions, viewport-aware submenu positioning, keyboard traversal, and only suppressing the browser context menu on tables that opt in. Rebuilding that means owning a coupling to Filament internals across every upgrade.
• Scope discipline for v1. Touch and long-press are explicitly out of scope in v1. That's a decision you can accept knowingly rather than discovering after commit.

When to Consider This Package

Adopt when:

• You are on Filament v4 or v5 and already own a Filament panel — the integration is composer require, one plugin registration, one ->contextMenuActions([...]) call. Cost of a spike is measured in hours.
• Your tables have more than ~3 row actions per record, or any destructive action that currently sits in the row column competing for attention.
• Your user base is desktop-first and repeat-use (internal tools, back-office, ops consoles) — the audience that discovers and retains right-click.
• You are also running Flowforge; Kanban card support is free and shares the same mental model.
• You want the authorization story to stay boring. Server-side hidden/disabled/authorization checks are untouched — a hidden action refuses to mount, and no client-side policy decision is made. Security review surface is effectively zero.
• You can pin the version and absorb Filament major-version churn on your own timeline.

Look elsewhere or defer when:

• Mobile or touch-primary users. Long-press is intentionally absent; a context menu is effectively unreachable for that cohort. You'd be building a feature only half your users can invoke.
• Discoverability is a core requirement. Right-click is invisible. If the action must be found by new or infrequent users, a visible action column or an overflow ActionGroup is the better call. (Keyboard ContextMenu / Shift+F10 support mitigates but does not solve this.)
• You are on Filament v4 and want the v2 line. v2.0.0 dropped v4 support and requires Filament ≥5.6.4; v4 users are frozen on the 1.x branch. If your panel upgrade is not planned, budget for carrying a legacy branch.
• Procurement risk tolerance is low. 40 stars, zero dependents, single-maintainer, MIT. It is a well-scoped and actively released package (through v2.0.0), but it is not a de-risked dependency for a tier-1 revenue surface. Treat it as a convenience layer, not infrastructure.
• Your table action set is small and stable. Below roughly three actions, the menu is a net cognitive cost — you've hidden things that were already cheap to see.

How to Pitch It (Stakeholders)

For executives (one line): A small, MIT-licensed UX add-on for our Filament admin that lets operators act on records via right-click — the interaction pattern our users already expect from Linear and desktop tools — for roughly a day of integration effort and no new security surface.

For engineering (the honest version):

• It is a thin wrapper, not a framework. Menu entries are static metadata (label, icon, color, sections, separators, nested submenus); the actual work is always a native Filament Action or BulkAction. Modals, confirmation, validation, notifications, redirects, and authorization stay owned by Filament — we inherit v1.4.0's icon/color inheritance from the wrapped action, so we don't duplicate config.
• No new authorization code path. Hidden, disabled, and unauthorized actions simply refuse to mount. Nothing about policy lives in the browser.
• Costs we should plan for: one plugin registration line, one php artisan filament:assets step in deploy, and loadedOnRequest() assets that only load on tables that opt in — so zero cost on tables that don't. If we bundle assets ourselves, there's a documented DOM contract to preserve; otherwise leave it alone.
• Constraints to accept up front: no touch/long-press in v1; browser context menu is only suppressed on opted-in tables (good — no site-wide surprise); and v2 pins us to Filament ≥5.6.4, so this rides our panel upgrade, not ahead of it.
• Maintenance posture: MIT, single maintainer, small audience. Vendor it or pin it, keep the usage surface narrow (a handful of tables), and treat removal as a config change rather than a rewrite — the actions it wraps are ours and survive the package going away.

Recommendation: approve a timeboxed spike on one or two high-frequency tables — the highest-action-count table and, if we run Flowforge, one Kanban board. Success criteria: fewer visible row actions, no increase in support tickets about "can't find action X," and no auth regressions. If those hold, expand table by table; if the discoverability cost shows up in tickets, we've lost two days and learned something about our users.