Crud Laravel Package

Product Decisions This Supports

• Whether to standardize internal back-office tooling on Orchid Platform. orchid/crud is not a standalone CRUD library — it is the screen-generation layer of Laravel Orchid (screens, layouts, fields, columns, filters, actions). The decision it actually informs is "do we make Orchid our admin platform?" Once that is yes, this package is the cheap marginal add-on that turns each new entity into a declarative screen instead of a hand-built controller/view pair. Evaluated alone, it is not a decidable question.
• Build vs. buy vs. adopt for internal tools. Adopting this is a deliberate trade of design flexibility for speed on ops consoles, support dashboards, and internal admin — explicitly not customer-facing surfaces. It should be weighed against bespoke Blade/Livewire, Filament/Nova, or a purchased admin product, with the declined alternative written down.
• Internal-tool roadmap capacity. Screens are cheap here, so PMs can accept broader internal-tool scope without proportional headcount — provided the plan budgets for Orchid-specific skills. General Laravel fluency does not transfer 1:1 to screens/layouts/fields, and pretending it does is how internal-tool roadmaps slip.
• Laravel 12 migration sequencing. 4.4.0 adds Laravel 12 support, clearing a dependency that may have pinned a team to Laravel 11. Treat it as an item in the framework-upgrade workstream — and verify orchid/platform itself supports Laravel 12 before committing a date, because CRUD cannot outrun its host.
• Least-privilege and audit posture. The new hide method lets teams declaratively gate action visibility per role or record state — hiding "Refund," "Approve," or "Impersonate" from users who shouldn't see them. Useful evidence in security reviews and reduces hand-maintained screen logic. PM caveat: hiding is not authorizing. The server-side permission check must still exist; hide is UX and information-disclosure hygiene, not the control.
• Support-impersonation and multi-tenant admin flows. The displayInNavigation null-user fix changes behavior for menus rendered without an authenticated user — relevant wherever tenant-scoped navigation, guest-reachable admin routes, or staff impersonation exist. Owners of those flows should be told it shipped and re-verify them.
• Explicit non-decisions. Nothing in this release moves public-facing UI, marketing surfaces, API design, or differentiation. Do not fold an admin-layer upgrade into a product narrative.

When to Consider This Package

Consider it when:

• You are already on, or deliberately adopting, Orchid Platform. Evaluate CRUD together with Orchid, never in isolation — otherwise "adopt CRUD" really means "adopt Orchid, then CRUD," i.e., two onboarding efforts, not one.
• You need many entity CRUD screens quickly and the audience is internal/operator-facing — conventional forms and tables are fine, design differentiation is not required.
• You are on Laravel 11 or 12, with 4.4.0 a non-breaking minor over 4.3.x (no deprecations, no config changes, no migrations).
• You want role- or state-based action visibility expressed declaratively on the screen rather than scattered across controllers.
• You have a small, Laravel-fluent team facing weeks of bespoke admin work per screen.
• You can accept community maintenance with a named internal owner, pinned versions, and an admin smoke test.

Look elsewhere when:

• You need a brand-differentiated or public-facing UI; Orchid's abstractions are opinionated and resist design-led surfaces.
• Your stack is Inertia / React / Vue / API-first or headless-admin. The value is server-rendered Blade screens; if the admin roadmap is trending SPA, this is the wrong direction regardless of package quality.
• You need vendor SLAs, scheduled security backports, or commercial support. The contributor base is small, cadence irregular, the ecosystem signal is thin (0 dependents), and adoption means being an early, self-supporting consumer with little external battle-testing.
• You need audit logging, field-level permissions, or approval workflows out of the box — budget to build them.
• You are on Laravel 10 or older, or an Orchid version this release does not pair with.
• You want a slow-moving admin contract. CRUD tracks Orchid's release cadence, so upgrades are paired, not independent.

Due diligence before committing: confirm which Orchid Platform version pairs with CRUD 4.4.0 and that that version supports Laravel 12; re-test guest, tenant-scoped, and impersonated navigation; pilot hide on one screen to confirm it composes with existing permission gating rather than conflicting (it is opt-in — no migration, no behavior change until adopted, so it can safely defer past the upgrade window); and explicitly record the alternative you are declining and why.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release of the open-source admin layer behind our internal tools — no license cost, no breaking change, no new operational burden. Two things matter commercially. First, Laravel 12 support clears a dependency that was blocking a framework upgrade, keeping us on a supported runtime for security patching. Second, it gives us a clean, declarative way to hide sensitive admin actions from users who shouldn't see them, lowering the cost of meeting least-privilege expectations. The risk profile is unchanged and worth stating plainly: community-maintained, small contributor base, no commercial SLA, and a package with essentially no downstream dependents — so we would be an early, self-supporting consumer. Our real exposure is expertise concentration: a handful of engineers understand the screen/layout/field layer. Mitigate with a named owner, internal pattern documentation, pinned and version-locked dependencies, and an admin smoke test. That is a staffing and documentation task, not a reason to change direction.

For engineering: 4.4.0 is a minor, non-breaking release from 4.3.0 with three changes — an opt-in hide method for conditional action visibility (existing screens behave identically), a fix for request()->user() being null in displayInNavigation (this one does change behavior on guest, tenant-scoped, and impersonated navigation — for the better, but test it), and Laravel 12 compatibility. Upgrade is a composer bump plus a smoke test; no deprecations, no config changes, no migrations. Before committing to Laravel 12, verify Orchid Platform itself supports it. Then pilot hide on a single screen, confirm it interacts correctly with existing permission gating, and roll out incrementally. If we are migrating from bespoke Blade/Livewire admin rather than from Orchid 4.3.x, scope that as re-platforming, not a library swap — screen-by-screen reimplementation plus an explicit mapping from our authorization model onto Orchid permissions, with per-screen acceptance criteria. Keep Orchid and CRUD version-locked, review both on Laravel's annual cycle, and make sure at least two engineers can work in the screen abstractions.