Panel Laravel Package

Product Decisions This Supports

• Authorization posture / security sign-off. v1.1.2 closes an IDOR/BOLA class gap: relation manager routes, nested resource routes, and the reorder route now enforce model policies alongside the parent resource. This is the kind of finding that blocks a security review or a SOC 2 / pen-test sign-off, so the release directly supports a "ship to enterprise/regulated customer" decision rather than a "harden later" deferral.
• Multi-tenant and delegated-admin roadmaps. Because nested child lookups are now scoped to the parent record, the package becomes viable for tenant-scoped back offices and partner/customer-facing admin surfaces where a user must not reach records outside their parent object. Previously this required custom guards or accepting residual risk.
• Build vs. buy for admin/back-office. Every hardening release that lands upstream reduces the argument for a bespoke internal admin panel. Each enforced-route class (list, create, update, delete, bulk delete, reorder) is engineering work you no longer own.
• Upgrade scheduling decision. This is a patch-level bump with a behavioral change, not just a bug fix. It belongs in the next maintenance window, but the 403 surface is new — it needs a regression pass over existing relation managers and nested resources before it goes to production.
• Feature sequencing. Granular permission UX (who can reorder, who can bulk delete) is now backed by real enforcement, so permission-management UI and audit-log features can be prioritized with confidence that the underlying checks exist.
• Risk acceptance documentation. "Models without a registered policy behave as before" means the security gain is conditional on your policy coverage. That is a decision point: audit which models lack policies, and treat that list as accepted risk or as roadmap work.

When to Consider This Package

Adopt when:

• You are on Laravel and need an admin/back-office layer with resource CRUD, relation managers, nested resources, and reordering — i.e. a Filament-class problem.
• You already model authorization with Laravel policies, or are willing to. The v1.1.2 guarantees are policy-driven; the value is captured only if policies exist.
• You operate multi-tenant or delegated-admin surfaces where cross-record access is a real threat, not a theoretical one.
• You want security fixes to arrive as upstream patches instead of in-house maintenance.
• Your team is small enough that owning a bespoke admin panel is a poor use of headcount.

Look elsewhere when:

• You need field-level or record-state-level permissions, custom approval workflows, or non-policy authorization models — you will fight the abstraction.
• You are not on Laravel, or you run a heavily customized non-Eloquent data layer.
• You require a vendor with a formal support contract, SLA, and published security disclosure policy; a patch release referencing a GitHub issue is not that.
• Your admin surface is customer-facing at scale and you need design-system-level control over every screen.
• You cannot absorb a behavior change mid-cycle: teams with broad registered policies that were never written with relation-manager, nested, or reorder routes in mind should expect new 403s and must schedule testing.

How to Pitch It (Stakeholders)

For executives: This is a small dependency update with an outsized risk payoff. It closes a class of access-control gap where a logged-in admin could act on records through nested and relation routes without the same permission checks that guard the main screens. For anyone selling into enterprise, undergoing a security questionnaire, or running a multi-tenant product, that gap is exactly what auditors and pen-testers flag. Cost is one composer update; benefit is removing a finding from the security review and reducing our own custom authorization code. The caveat worth stating plainly: the protection applies to models that have policies registered, so this update makes our policy coverage matter more, not less.

For engineering: Patch release, no API changes, one command. Two things to action. First, behavior change: relation manager routes, nested resource routes, and reorder now enforce the parent record being viewable plus the related model's policy — or the nested resource's canX() — and abort with 403 otherwise. Reorder requires the reorder ability and falls back to the policy's update ability. Second, nested child lookups are now scoped to the parent, so any code that relied on reaching a child outside the parent's scope will break — that is the point, but it needs a test pass. Audit which of our models are still without policies, since those keep the old permissive behavior. Regression-test bulk delete and reorder specifically, as those are the most likely to surprise existing admin users.