Open
Conversation
Vouchers now store which domain they are valid for. During registration, the voucher determines the domain of the new user account instead of always using the default domain. Key changes: - Add DomainAwareTrait to Voucher entity with NOT NULL constraint - Introduce VoucherManager service replacing VoucherCreator, VoucherFactory and VoucherHandler with unified create/permission/auto-create logic - Registration form receives domain from voucher instead of querying the default domain at construction time - CLI command gains --domain option (defaults to user domain) - VoucherAdmin updated with domain field, filter and list column - Migration backfills existing vouchers with the default domain Co-Authored-By: OpenCode <noreply@opencode.ai>
0x46616c6b
force-pushed
the
feature/voucher-domain
branch
from
0a0df6f to
96d888a
Compare
0x46616c6b
requested review from
doobry-systemli,
t2d and
y3n4
as code owners
Display the associated domain for each voucher (active and redeemed) on the user-facing voucher page. Remove the obsolete domain == user_domain guard that blocked the voucher section for users on non-default domains. Co-Authored-By: OpenCode <noreply@opencode.ai>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
domainfield toVoucherentity viaDomainAwareTrait(ManyToOne, NOT NULL), so each voucher stores which domain it is valid for. During registration, the voucher now determines the domain of the new user account.VoucherManagerservice (src/Service/VoucherManager.php) consolidatingVoucherCreator,VoucherFactory, andVoucherHandlerinto a singlefinal readonlymanager withcreate(),assertDomainPermission(), andgetVouchersByUser()methods.RegistrationTypereceives the domain as a form option (from the voucher) instead of querying the default domain at construction time. The template shows the voucher's domain in the title, subtitle, and email suffix.domain == user_domainguard that blocked the voucher section for users on non-default domains.--domainCLI option toapp:voucher:createcommand (defaults to user's own domain).VoucherAdmin) with domain field in form, list column, and datagrid filter.Permission model
ROLE_ADMIN: can create vouchers for any domainVoucherManager::assertDomainPermission())DomainFilter(Doctrine SQL filter) now auto-applies to Voucher viaDomainAwareTraitThe changes and the PR were generated by OpenCode.