Consent Bundle Laravel Package

Getting Started

Read this first: this is a Symfony bundle, not a Laravel package. There is no service provider, no config/consent.php, and no facade. If you are working inside a Laravel codebase you will either (a) pull it in as a dependency of a Symfony sub-application, or (b) treat it as a reference implementation and re-implement its consent-recording logic with Eloquent. Plan for that mismatch before you run composer require vouchedfor/consent-bundle.

Minimal steps in a Symfony app:

1. composer require vouchedfor/consent-bundle.
2. Register the bundle in config/bundles.php (Symfony Flex may do this for you): VouchedFor\ConsentBundle\ConsentBundle::class => ['all' => true].
3. Check Resources/config/services.yml (or config/services.xml) inside the vendor directory first — this tells you the service IDs, the consent manager interface, and the Doctrine entity mappings you will actually inject.
4. Inspect the entities in Entity/ (typically a Consent record tying a user/subject to a consent type, a source, a timestamp, and an action taken/granted flag). This is the schema you will live with.
5. Run bin/console doctrine:schema:update --dump-sql to see the tables it wants to create before migrating.

First real use case: record that a user has accepted your terms/privacy policy at signup, then query that consent later to decide whether to send marketing email. Inject the bundle's consent manager into your registration controller and call its record method — that is the whole loop.

Implementation Patterns

Record-on-action. The dominant pattern is: a user performs an action (signs up, ticks a box, submits a cookie banner) → you call the consent manager with the subject, consent type, and a flag. Persist the surrounding context yourself (IP, user agent, policy version, form payload) because consent evidence is only useful if you can prove what they agreed to and when.

Guard-on-read. Before sending marketing, before setting non-essential cookies, before processing under a legal basis of consent, ask the manager "does subject X currently consent to Y?" Wrap that check in your own small service so controllers do not depend on the bundle directly — this makes the eventual replacement (or Laravel port) a one-file change.

Event/observer integration. If the bundle dispatches events on grant/withdraw (check Event/ and EventSubscriber/), subscribe to them to propagate consent changes to your CRM or mail provider. Treat withdrawal as first-class: the valuable behaviour is usually "user revoked marketing consent → stop sending," not "user granted it."

Versioned consent types. Model policy versions as distinct consent types (e.g. terms_v1, terms_v2) rather than overwriting a boolean. Re-prompting on a policy change then becomes a data query, not a migration.

Transactional writes. Record consent in the same transaction as the action it accompanies (e.g. the user row insert). A consent record that exists without the user, or vice versa, is an audit liability.

Testing. Because the bundle is thin and Doctrine-backed, unit-test your wrapper service against an in-memory SQLite/sqlite Doctrine connection rather than mocking the bundle's internals — you get real coverage of the persistence path.

Gotchas and Tips

• Symfony, not Laravel. There is no Laravel adapter. If you need it under Laravel you must either run a Symfony kernel alongside (messy) or reimplement. Budget for the latter.
• Doctrine coupling. The bundle expects Doctrine ORM. Laravel's Eloquent will not understand the entity mappings. If porting, translate the entity annotations/attributes into a migration by hand.
• Adoption is essentially zero (1 star, 0 dependents). Do not assume bug-free behaviour on edge cases; read the service definitions and entities line by line before trusting the public API. Pin the exact version in composer.json.
• Symfony/PHP version constraints. Check composer.json in the vendor directory — an old bundle may cap symfony/* at a version your stack has moved past, forcing you to loosen constraints or patch.
• Schema changes need migrations. The bundle supplies entities but likely not migrations. Generate your own Doctrine migration so schema changes are reviewable rather than applied silently via schema:update.
• Consent withdrawal is the hard part. Make sure the manager exposes a revoke/withdraw path and that your downstream systems honour it; a grant-only implementation is a compliance risk, not just a feature gap.
• Extension points are the events and the manager service. If you need custom storage or an audit trail, decorate the manager service (Symfony service decoration) rather than editing vendor code.
• Debugging tip: bin/console debug:container --show-private | grep -i consent will reveal the real service IDs, which are the fastest route to understanding the API when docs are missing.
• Treat it as a spec, not a dependency. Given the maturity, the highest-value use is reading its consent model and rebuilding that model in your own application with your own tests.