Actions Laravel Package

Getting Started

• Install the package (composer require laravilt/laravilt) and pull in its companion packages (laravilt/panel, laravilt/actions) at compatible versions — v1.1.1 is a coordinated patch across all three, so keep them in lockstep.
• First place to look is the generated panel provider and config/laravilt.php. Register a panel, then let the package discover your resources. Confirm the resource → model → policy wiring before customising anything.
• First use case: take one existing Eloquent model, generate a Resource for it, create a matching Policy, and verify that a non-privileged user cannot see or mutate records they shouldn't. This is exactly the path the v1.1.1 fix targets, so it's the right smoke test.
• Upgrade note: if you pinned earlier 1.1.x versions, bump laravilt/laravilt, laravilt/actions, and laravilt/panel together (see laravilt/laravilt#21, #25 and the referenced actions#18 / panel#20 fixes).

Implementation Patterns

• Policy-first resources. Define standard Laravel policies (viewAny, view, create, update, delete, plus custom abilities) and let the resource/action layer consult them. After v1.1.1 these are actually respected for resource permissions, so authorise through policies rather than hand-rolling checks in resource classes.
• Gate custom abilities for row/action-level control. Map non-CRUD actions to policy methods and reference them from action definitions, so both resource visibility and per-row action visibility derive from a single authorisation source.
• Panel-scoped authorisation. In multi-panel apps with separate guards, keep policies panel-aware (e.g. check the active panel/guard inside the policy) rather than branching inside resources. This survives panel additions cleanly.
• Actions as composable units. Attach actions to resources/tables/forms and gate them with the same ability names used in policies. Prefer declarative visibility/authorisation on the action over conditional if blocks in the surrounding resource code.
• Test authorisation explicitly. Use actingAs() with users of each role and assert both resource access and action visibility. Because permissions were previously not enforced, add regression tests around the flows covered by #21/#25 so a future upgrade doesn't silently reopen them.
• Integration tip: centralise role/super-admin bypasses in a single Gate::before (or equivalent) rather than sprinkling bypasses through resources; this keeps policy behaviour predictable and auditable.

Gotchas and Tips

• Behaviour change from v1.1.1. Resource permissions and policies are now honoured where they previously weren't. If you added manual can()/role checks or hid actions defensively to work around the old behaviour, those workarounds are now redundant and may double-gate or conflict. Audit and remove them.
• Expect newly-hidden UI. Users who previously saw resources/actions they had no policy for will now correctly lose access. Treat this as a fix, not a regression, but communicate it before rolling out.
• Clear caches after upgrading. Run php artisan config:clear (and your route/view caches) so the updated permission wiring and any published config changes take effect; stale caches are a common source of "the fix didn't work".
• Ability-name mismatches fail silently. If a policy method name doesn't match what the resource/action expects, access is simply denied. Debug by checking the policy methods the resource resolves, not just the policy class existence.
• Guard/panel scoping is a frequent footgun. Policies resolving the wrong guard in multi-panel setups will deny everything; verify the active panel's guard when authorisation behaves unexpectedly.
• Extension points: keep policy logic in policies and use Gate::before/Gate::after for cross-cutting rules; reserve resource-level overrides for genuine presentation concerns so upgrades to the authorisation layer don't require reworking them.