Weave Code
Permissions Laravel Package
laravel-enso/permissions
Laravel Enso Permissions provides role and permission management for Enso-based Laravel applications, letting you assign permissions to roles and control user access through Laravel’s authorization layer. It integrates with Enso’s UI and core modules to simplify access-control administration.
Laravel Enso Permission Manger interface for easy management of access to your application's resources
Frequently asked questions about Permissions
- What is laravel-enso/permissions and what does it actually do?
- It is the permissions management UI layer of the Laravel Enso ecosystem, providing the Vue components, routes, controllers, tables and forms that let an administrator assign roles to users and permissions to roles. It does not try to be a general-purpose authorization library; enforcement runs through Laravel's authorization layer. Its value is ergonomic rather than architectural, so it only makes sense inside an application already built on Enso conventions.
- Can I use laravel-enso/permissions in a plain Laravel app without Enso?
- Realistically, no. The package assumes a host application shaped by Enso conventions: route and menu registration through enso/core, resource tables via enso/tables, forms via enso/forms, and the Enso structure and permission tree. Outside that shell it is a UI fragment without its skeleton. The realistic path is to adopt enso/core and its dependency closure first, then add this package on top.
- How do I install laravel-enso/permissions?
- You install it with Composer, but only after the Enso core stack is present, since the package depends on enso/core and the wider enso/* dependency set. In an existing Enso application, installation is a composer require plus a permission tree sync step, followed by any required migrations. Check the repository's composer.json and README for the exact commands and ordering for your Enso version.
- Which Laravel and PHP versions does laravel-enso/permissions support?
- The supported Laravel and PHP versions are defined by the package's composer.json constraints and by the Enso core releases it tracks, not by an independent versioning policy. Because Enso is opinionated about its stack, you should pin this package alongside a known-good enso/core release rather than resolving it in isolation. Always verify the current constraints in the repository before planning an upgrade.
- Does laravel-enso/permissions wrap spatie/laravel-permission or implement its own tables?
- The package is best understood as the Enso management surface for roles and permissions, and the underlying data model and enforcement semantics come from the authorization layer the Enso stack uses. To confirm whether spatie/laravel-permission is the actual backing implementation for your version, inspect the composer.json and the package's migrations and models. This matters because it determines how permission checks are enforced outside the UI and how portable your authorization data is.
- How are permissions defined and kept in sync in Enso?
- In Enso, permissions map to application resources and menu structure rather than being free-form strings, and they are typically synchronized through a permission tree step. A manifest-driven, syncable definition is auditable and CI-diffable, whereas purely ad-hoc creation through the UI is drift-prone. Confirm which mode your Enso version uses before relying on it across environments.
- Is the Enso admin UI on Vue 2 or Vue 3?
- Enso's frontend is historically Vue 2, which is end-of-life, and any move to Vue 3, Inertia or Vite-based tooling depends on the upstream ecosystem's migration rather than on anything you control. That makes the frontend lifecycle a real planning consideration if you expect long-term support. Verify the current frontend stack of the Enso release you intend to run.
- Is laravel-enso/permissions safe to expose in production?
- Permission management screens are a classic privilege-escalation target because they involve role editing, self-assignment and potentially impersonation. This package has low independent adoption and a small maintainer team, so you should review its controllers and route middleware yourself instead of inheriting trust. Add explicit guardrails against self-elevation and restrict who can reach the role-assignment endpoints.
- What are the alternatives to laravel-enso/permissions?
- If you are not running Enso, the honest options are to adopt spatie/laravel-permission directly and build a modest admin screen, or to adopt the full Enso stack deliberately with this package as one component of that decision. Choosing this package purely to solve a need for a permissions UI is the tail wagging the dog. Pick it because you want Enso, not because you want a permissions screen.
- Is laravel-enso/permissions actively maintained, and what is the bus factor risk?
- The package has very low independent adoption and is maintained by a single commercial vendor with a small maintainer pool, which is a strong signal it is used as an internal Enso component rather than an independently evaluated dependency. That concentration is a real risk for a security-sensitive admin surface. Because permissions are expressed as Enso resources and menu structure, your authorization model also becomes entangled with the Enso structure tree, so extracting it later is a rewrite of the assignment surface rather than a swap.
Weaver
How can I help you explore Laravel packages today?