Panel Laravel Package

Getting Started

Install the package with composer require laravilt/laravilt, run any package install command, publish config/migrations, and migrate. Start by reading the package docs for resources, relation managers, and nested resources, then inspect your generated resource classes and config/laravilt.php for route registration and middleware.

Your first practical use case after v1.1.2: take an existing relation manager, add a Laravel policy for the related model, and verify the route behavior as both an authorized and unauthorized user. The release makes relation-manager routes policy-aware, so this is the quickest way to confirm your authorization model matches the new enforcement. Remember that models without a registered policy continue to behave as before, so start by adding policies to sensitive models rather than assuming every route is locked down.

Implementation Patterns

• Policy-first resources. Generate policies with php artisan make:policy, register them through Laravel auto-discovery or AuthServiceProvider, and implement the abilities your resources use: viewAny, view, create, update, delete, deleteAny, and optionally reorder. The package now checks both the parent record’s viewability and the related model’s policy for relation-manager list, create, update, delete, bulk delete, nested resource routes, and reorder routes.
• Relation managers. Use the relation manager’s canViewAny(), canCreate(), canUpdate(), canDelete(), and bulk-delete authorization hooks to hide UI actions, but rely on the underlying policy for route enforcement. A user must be able to view the parent record and the related model policy must allow the action; otherwise the request aborts with 403.
• Nested resources. If you do not want a full policy for a nested resource, implement the nested resource’s canX() methods. The package uses those checks where available and falls back to the related model’s policy. Child lookups are scoped to the parent record, so cross-parent child IDs should not resolve.
• Reorder. Implement a reorder ability on the policy when reordering should be more restrictive than editing. Without one, the package falls back to the policy’s update ability. If you use a custom canReorder() method, keep it aligned with the policy behavior.
• Bulk operations. Bulk delete on relation managers requires the related model’s bulk-delete ability in addition to parent view access. Test this separately from single-record delete because policy method names and semantics differ.
• Testing workflow. Write feature tests that hit each relation-manager and nested-resource route with actingAs. Assert 403 for unauthorized users, successful responses for authorized users, and non-resolution for child records belonging to another parent. This is especially important after upgrading because routes that previously succeeded may now return 403.
• UI consistency. Use Gate::allows() or the resource’s authorization helpers to drive button visibility, and let the route-level checks enforce the same rules. Avoid duplicating ad-hoc abort_unless logic in custom actions when a policy or canX() method can express the rule once.

Gotchas and Tips

• Enforcement is opt-in per model. Models without a registered policy behave as before. Do not assume v1.1.2 secures every relation manager automatically; add policies to all sensitive models.
• Parent viewability is required. Even create, update, and delete actions on a relation manager require the parent record to be viewable. A user who can edit a related model but cannot view its parent will receive 403. This is intentional but can surprise existing test suites.
• 403 versus 404. Unauthorized relation and nested-resource routes abort with 403. Cross-parent child lookups may instead fail to resolve and produce a 404 because child lookups are scoped to the parent. Debug these differently: 403 usually means policy denial; 404 can mean scoping worked as intended.
• Reorder is easy to over-permit. If no reorder ability exists, update grants reorder access. Define an explicit reorder policy method when ordering changes should be treated as a separate privilege.
• Nested resource canX() precedence. The package supports nested resource canX() checks alongside model policies. Be consistent about which layer owns each decision; mixed policy and canX() rules can make failures hard to trace. Test both authorized and unauthorized paths after changing either layer.
• Clear policy caches after adding policies. Laravel’s policy discovery can be cached. Run php artisan optimize:clear if a newly added policy is not being picked up in local or deployed environments.
• Debug routes with Laravel tooling. Use php artisan route:list --path=... to confirm which middleware and route names are active, and use Gate::getPolicyFor(Model::class) to verify policy registration. Check middleware order if a request is blocked before reaching the package’s authorization checks.
• Upgrade carefully. Update with composer update "laravilt/*" and run your authorization feature tests before deploying. Expect formerly allowed relation-manager routes to start returning 403 until policies are in place. Add the missing policies first, then deploy the package update.
• Extension points. Prefer custom policies, nested resource canX() methods, and relation manager authorization hooks over controller-level shortcuts. These are the supported places to customize authorization while keeping UI visibility and route enforcement consistent.