- What is idavoll/user-module used for?
- It is a reusable Laravel user module for Idavoll/Asgard applications, packaging user CRUD, authentication routes and controllers, profile management, migrations, and admin integration. It is intended to be dropped into an existing Asgard module-loader setup rather than used as a standalone Composer library. For greenfield Laravel projects, first-party auth options such as Breeze, Jetstream, or Fortify are the relevant choice.
- Does idavoll/user-module support Laravel 10, 11, or PHP 8?
- No, its version constraints target PHP 5.x/7.0 and Laravel 4.2 through 5.x, so modern Laravel 9/10/11+ and PHP 8.1+ stacks are out of scope. Composer resolution will either fail or require extensive transitive pinning. If your target is Laravel 8 or later, stop evaluating this module by constraint alone.
- How do I install idavoll/user-module?
- The theoretical install is a Composer require for idavoll/user-module, but there are no install reports or field evidence of a clean install today. It also expects the Idavoll/Asgard module loader and sibling modules for media, settings, and admin navigation. Treat installation as an internal integration project with a fork and pinned commit, not a drop-in Composer step.
- Is idavoll/user-module compatible with Laravel Breeze, Jetstream, or Fortify?
- No, it predates the guard and provider contracts those first-party packages use and hard-references the Idavoll/Asgard module loader. Mixing it with Breeze, Jetstream, or Fortify would create conflicting auth scaffolding rather than a clean integration. For new applications, use one of those first-party options and re-implement only the portable user data model.
- Is idavoll/user-module safe for production authentication?
- It owns security-critical surfaces such as login, password reset, user CRUD, and role/permission assignment, but it has no maintainer, advisory pipeline, or CVE response process. A read-only codebase means any vulnerability becomes an internal fork obligation with no upstream fix path. Production use would also freeze the host app to EOL PHP and Laravel versions, failing compliance audits independently of code quality.
- What license does idavoll/user-module use?
- The repository reports NOASSERTION, with no detected SPDX identifier. That usually means custom or malformed license text, so the literal grant must be obtained before any engineering time is spent. For a module that handles authentication and password reset, an unclear license is a legal and OSPO stop.
- What dependencies does idavoll/user-module require?
- It is a module, not a standalone library, and registers service providers, admin routes, Blade view namespaces, and migrations against the Idavoll/Asgard module loader. It hard-references sibling modules such as Media for avatars, Setting for configuration, and Menu/Dashboard for admin navigation. Expect aggressive transitive pinning if you attempt an install on a current stack.
- Can I use idavoll/user-module in a new Laravel project?
- No, the architecture does not fit greenfield Laravel services because the ecosystem moved to first-party auth with guard and provider contracts this code predates. The only coherent fit is an existing AsgardCMF deployment that still consumes it. For anything new, use Breeze/Jetstream plus Fortify and spatie/laravel-permission, or evaluate a maintained CMS platform as a whole.
- How do I migrate away from idavoll/user-module?
- If a legacy deployment must survive, fork from the maintained AsgardCMS/Platform monorepo rather than this read-only fragment, pin to a specific commit SHA, vendor it under an internal namespace, and register it as a held dependency. For new work, replace auth with Laravel Breeze/Jetstream and Fortify, roles with spatie/laravel-permission, and admin with Filament or Nova. Re-implement the small portable data model rather than porting the module code.
- Is idavoll/user-module maintained?
- There is no evidence of active maintenance: zero stars, zero dependents, no install reports, and a read-only repository. An unclaimed vendor namespace on a zero-adoption package is also a supply-chain risk for Composer identity re-registration. Treat the package identity as unstable and plan an exit or fork strategy if it is already in production.