Weave Code
Laravel Legal Consent Laravel Package
maize-tech/laravel-legal-consent
Laravel package for managing legal consents and compliance. Track user acceptance of terms, privacy policies, and other legal documents, handle versioned agreements, and maintain an auditable consent history in your application.
Easily integrate legal documents to your application
Frequently asked questions about Laravel Legal Consent
- How do I install maize-tech/laravel-legal-consent in a Laravel application?
- Install it with Composer using composer require maize-tech/laravel-legal-consent, then publish the package migrations and configuration and run php artisan migrate. You then apply the supplied trait to your existing user model and wire consent capture into registration, checkout, or account flows. The mechanical setup is small and typically measured in days, not sprints. Plan extra time for deciding which documents need consent, your versioning scheme, and the audit export legal will request.
- Which Laravel and PHP versions does this package support?
- Version 3.3.0 states support for Laravel 11 through 13 and PHP 8.2 through 8.5. Projects on Laravel 10 or PHP 8.1 will be silently held at 3.2.x by Composer, which is effectively an unannounced end of maintenance for the older line. Treat Laravel 13 and PHP 8.5 as supported upstream but unproven in your application until you test them. Also verify JSON column and index-length expectations against your database engine before committing.
- How do I attach legal consent tracking to my existing User model?
- The package ships a trait designed to add consent behaviour to your existing Eloquent user model, along with models for legal documents and consent records. You import the trait and add it to the User class, then call its methods from your registration, checkout, or account settings flows. This is a standard capability bolt-on with no external services or async infrastructure. Keep the trait usage thin and put your own policy logic, such as which documents are required, in application code.
- What is actually stored for each consent record and can I export it as an audit trail?
- The package provides Eloquent models for consent records, but you should confirm the schema records document identity, document version, timestamp, and sufficient provenance such as user ID, IP address, or user agent if you need it. You should also verify whether records are immutable once written. The package's value is the audit artifact it produces, so evaluate record fidelity before ergonomics. Building the audit or export view that legal actually asks for is application work, not something the package ships.
- How are legal document versions handled and is re-consent enforced when a version changes?
- The package is built around versioned agreements and stores the accepted document version with the consent record. What is not clearly documented is whether a version bump enforces re-consent or merely makes it advisory. Verify that behaviour in your integration and build your own check on login, signup, or checkout if enforcement matters. Do not assume re-consent is automatic without testing it.
- What happens to consent records when a user is deleted?
- This is a key question to verify before adopting the package, because the documented material does not state whether consent records cascade, become orphaned, or are anonymised on user deletion. GDPR right-to-erasure can collide with keeping proof of consent, so decide your retention and anonymisation policy up front. Test the actual foreign-key behaviour in a staging database and configure or override it if needed. You likely own archival and purge strategy rather than getting it from the package.
- Can I capture consent from guests or unauthenticated users?
- The package's primary integration path is a trait on an authenticated user model, and guest or anonymous consent capture is not clearly documented. If you need consent at signup before an account exists, you will probably need to store a session or provisional identifier yourself and reconcile it after registration. Verify whether the models allow a nullable user reference before designing that flow. For most terms and privacy policy acceptance, capturing consent immediately after authentication is simpler.
- Can I add custom columns to the consent tables or extend the package models?
- You can publish the migrations and configuration, which gives you control over the schema at install time. Adding columns later means deciding who owns the schema: extending the package models and overriding bindings, or forking the package. Check the documented config keys and public APIs before building against them, especially if you are upgrading from 3.2.x to 3.3.0. A minor release can include trait or config renames, so pin and test the upgrade.
- Is laravel-legal-consent a cookie consent banner or front-end consent management platform?
- No. This is a server-side package for tracking acceptance of legal documents such as terms of service, privacy policies, and DPAs. It is not a cookie banner or a front-end consent management platform, so scope those requirements separately. Use it where legal-document acceptance is a backend compliance concern, and pair it with a dedicated cookie consent tool if you need one. The domain here is compliance evidence, not convenience UI.
- Is the package actively maintained and how do I get support?
- Expect low release cadence, one substantive contributor on the functional changes, and no commercial backing, so plan for self-support. There is no clearly published security policy or guaranteed response time, which matters for a compliance dependency. Pin versions, monitor releases, and avoid pinning ^3.3 blindly across a mixed Laravel estate because the constraint resolves differently per application. The recent Pest, Pint, and Larastan migration is a quality positive, but expect a patch release or two to settle after the framework matrix change.
Weaver
How can I help you explore Laravel packages today?