app/Models/Foundation/Summit/Summit.php (1)

5555-5568: Keep promo-code visibility separate from purchase authorization.

Returning true here means models\summit\Summit::canBuyRegistrationTicketByType() no longer answers “can this email buy this ticket type?” for models\summit\SummitTicketType::Audience_With_Promo_Code; it only says the ticket is not invitation-gated. That makes the helper easy to reuse incorrectly later and accidentally bypass the promo-code requirement. Consider threading promo-code context into this check, or splitting visibility from authorization into separate helpers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Models/Foundation/Summit/Summit.php` around lines 5555 - 5568, The
current Summit::canBuyRegistrationTicketByType() unconditionally returns true
for SummitTicketType::Audience_With_Promo_Code which conflates visibility with
purchase authorization; instead remove the unconditional return and either (a)
add a promo-context parameter (e.g. $promoCodeProvided or $promoContext) to
canBuyRegistrationTicketByType and check promo validity before granting
purchase, or (b) split responsibilities by creating a separate visibility helper
(e.g. isTicketTypeVisibleToEmail or canViewTicketType) that returns true for
Audience_With_Promo_Code while leaving canBuyRegistrationTicketByType to enforce
promo-code checks; update callers to pass the promo context or use the new
visibility helper as appropriate.

app/Http/Controllers/Apis/Protected/Summit/OAuth2SummitPromoCodesApiController.php (1)

1585-1602: OpenAPI annotation missing fields and relations query parameters.

The implementation at lines 1617-1622 reads fields and relations from the request, but the OpenAPI annotation only documents the expand parameter. Consider adding the missing parameters for complete API documentation.

         parameters: [
             new OA\Parameter(name: "id", in: "path", required: true, schema: new OA\Schema(type: "integer")),
             new OA\Parameter(name: "expand", in: "query", required: false, schema: new OA\Schema(type: "string")),
+            new OA\Parameter(name: "fields", in: "query", required: false, schema: new OA\Schema(type: "string")),
+            new OA\Parameter(name: "relations", in: "query", required: false, schema: new OA\Schema(type: "string")),
         ],

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/Http/Controllers/Apis/Protected/Summit/OAuth2SummitPromoCodesApiController.php`
around lines 1585 - 1602, The OpenAPI annotation for the controller method (the
OA\Get block above discoverPromoCodesBySummit in
OAuth2SummitPromoCodesApiController) is missing the query parameters used in the
implementation; add two OA\Parameter entries for "fields" and "relations" (both
in="query", required=false, schema type="string") with brief descriptions (e.g.,
"Comma-separated list of fields to include" and "Comma-separated list of
relations to expand") so the documented parameters match the code that reads
fields and relations from the request.

app/Repositories/Summit/DoctrineSummitRegistrationPromoCodeRepository.php (1)

668-721: Discovery filtering logic is correct but has minor duplication.

The method correctly:

• Normalizes email to lowercase
• Uses INSTANCE OF to fetch only discoverable code types
• Applies type-specific matching (domain vs. owner email)
• Checks isLive() for all codes

The member and speaker code blocks (lines 702-716) share identical logic. Consider extracting to reduce duplication:

♻️ Optional refactor to reduce duplication

-            // Email-linked types: match by associated member/speaker email
-            if ($code instanceof MemberSummitRegistrationPromoCode || $code instanceof MemberSummitRegistrationDiscountCode) {
-                $ownerEmail = $code->getOwnerEmail();
-                if (!empty($ownerEmail) && strtolower($ownerEmail) === $email && $code->isLive()) {
-                    $results[] = $code;
-                }
-                continue;
-            }
-
-            if ($code instanceof SpeakerSummitRegistrationPromoCode || $code instanceof SpeakerSummitRegistrationDiscountCode) {
-                $ownerEmail = $code->getOwnerEmail();
-                if (!empty($ownerEmail) && strtolower($ownerEmail) === $email && $code->isLive()) {
-                    $results[] = $code;
-                }
-                continue;
-            }
+            // Email-linked types: match by associated member/speaker email
+            if (method_exists($code, 'getOwnerEmail')) {
+                $ownerEmail = $code->getOwnerEmail();
+                if (!empty($ownerEmail) && strtolower($ownerEmail) === $email && $code->isLive()) {
+                    $results[] = $code;
+                }
+            }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Repositories/Summit/DoctrineSummitRegistrationPromoCodeRepository.php`
around lines 668 - 721, The member and speaker owner-email checks inside
getDiscoverableByEmailForSummit are duplicated; extract the shared logic into a
small private helper (e.g., private function isOwnerEmailMatch($code, string
$email): bool) that reads $code->getOwnerEmail(), lowercases and compares to
$email and checks $code->isLive(), then replace the two separate blocks (the
checks against MemberSummitRegistrationPromoCode,
MemberSummitRegistrationDiscountCode and against
SpeakerSummitRegistrationPromoCode, SpeakerSummitRegistrationDiscountCode) with
either a single instanceof-any conditional that calls the helper or two concise
calls to the helper, leaving domain-authorized logic unchanged.

app/Rules/AllowedEmailDomainsArray.php (1)

70-73: trans() used with literal string instead of translation key.

The trans() function expects a translation key, not a literal message. As written, it will return the string as-is. For proper i18n support:

-        return trans('The :attribute must be an array of valid email domain patterns (`@domain.com`, .tld, or [email protected]).');
+        return 'The :attribute must be an array of valid email domain patterns (`@domain.com`, .tld, or [email protected]).';

Or define a proper translation key if i18n is required.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Rules/AllowedEmailDomainsArray.php` around lines 70 - 73, The message()
method in AllowedEmailDomainsArray currently calls trans() with a literal
string; replace it to use a translation key (e.g. use
__('validation.allowed_email_domains_array') or
trans('validation.allowed_email_domains_array')) in the message() method and add
the corresponding key/value in your language files
(resources/lang/{locale}/validation.php) so i18n works correctly; reference:
AllowedEmailDomainsArray::message().

app/ModelSerializers/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationPromoCodeSerializer.php (1)

21-48: Consider adding expand_mappings for allowed_ticket_types.

The promo code model includes an allowed_ticket_types relationship (inherited from SummitRegistrationPromoCode), and the parallel DomainAuthorizedSummitRegistrationDiscountCodeSerializer includes expand_mappings for this field. For API consistency, add the same mapping to the promo code serializer:

+    protected static $expand_mappings = [
+        'allowed_ticket_types' => [
+            'type' => \Libs\ModelSerializers\Many2OneExpandSerializer::class,
+            'getter' => 'getAllowedTicketTypes',
+        ],
+    ];
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/ModelSerializers/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationPromoCodeSerializer.php`
around lines 21 - 48, The serializer
DomainAuthorizedSummitRegistrationPromoCodeSerializer is missing an
expand_mappings entry for the inherited allowed_ticket_types relation; add a
protected static $expand_mappings property (matching the pattern used in
DomainAuthorizedSummitRegistrationDiscountCodeSerializer) that maps
'allowed_ticket_types' to the appropriate expansion key/serializer (e.g., the
allowed_ticket_types expansion that returns the ticket types collection using
the same serializer used elsewhere for ticket types), so API consumers can
expand allowed_ticket_types when calling the serialize method.

app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedPromoCodeTrait.php (1)

122-134: Add PHPDoc documentation for $company parameter — it's part of the interface contract across all promo code implementations.

The $company parameter is unused in this method but is retained for consistency with the base class signature SummitRegistrationPromoCode::checkSubject(), which is polymorphically implemented across all promo code trait variants (Member, Speaker, Speakers, Sponsor, DomainAuthorized). Add a brief PHPDoc note explaining its retention for interface compatibility:

/**
 * `@param` string $email
 * `@param` null|string $company Retained for interface compatibility; not used in domain-authorized validation
 * `@return` bool
 * `@throws` ValidationException
 */

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedPromoCodeTrait.php`
around lines 122 - 134, Add a PHPDoc block to the
DomainAuthorizedPromoCodeTrait::checkSubject method documenting the unused
$company parameter for interface compatibility; update the docblock to include
`@param` string $email, `@param` null|string $company Retained for interface
compatibility; not used in domain-authorized validation, `@return` bool and
`@throws` ValidationException so the method signature matches the
SummitRegistrationPromoCode::checkSubject contract and clarifies why $company is
intentionally unused.

app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationPromoCode.php (1)

51-58: This override doesn't implement the documented audience bypass.

Right now it only forwards to parent::addAllowedTicketType(), so the “regardless of audience value” behavior in the comment is not actually expressed here. Either remove the override/comment or put the intended bypass logic in this method.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationPromoCode.php`
around lines 51 - 58, The override addAllowedTicketType in
DomainAuthorizedSummitRegistrationPromoCode currently just calls
parent::addAllowedTicketType and does not implement the claimed "regardless of
audience" behavior; either remove this override and its comment, or implement
the bypass by directly adding the SummitTicketType to this promo's allowed
ticket collection without performing the parent's audience check (e.g., perform
the collection add/update inside addAllowedTicketType on
DomainAuthorizedSummitRegistrationPromoCode rather than calling
parent::addAllowedTicketType). Ensure you update or remove the doc comment to
match the actual behavior.

tests/oauth2/OAuth2SummitPromoCodesApiTest.php (1)

1085-1116: These skipped checkout tests won't catch regressions.

Right now the new quantity-per-account checkout path has no protection from this file because all three enforcement tests are permanently skipped. If the full OAuth/saga harness is too heavy, a narrower test around ApplyPromoCodeTask::run() would still cover the new guard.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/oauth2/OAuth2SummitPromoCodesApiTest.php` around lines 1085 - 1116, The
three checkout tests in OAuth2SummitPromoCodesApiTest.php are skipped and leave
the new quantity-per-account enforcement untested; add focused unit tests that
call ApplyPromoCodeTask::run() directly (instead of the full saga) to cover
over-limit, under-limit, and basic concurrency behavior: create tests that
construct an ApplyPromoCodeTask with mocked dependencies (e.g., promo
repository, order repository/count query, and any lock/persistence layer), stub
the member's existing redemptions count to simulate over-limit and under-limit
scenarios and assert the task throws the expected rejection or completes
successfully, and for concurrency simulate the reservation/count behavior via
mocks to assert the pessimistic-lock path; place these tests in
OAuth2SummitPromoCodesApiTest.php replacing the skipped methods
(testCheckoutRejectsOverLimitQuantityPerAccount,
testCheckoutSucceedsUnderLimitQuantityPerAccount,
testCheckoutConcurrentEnforcement) so ApplyPromoCodeTask::run() is directly
exercised.

tests/Unit/Services/DomainAuthorizedPromoCodeTest.php (1)

291-305: Vacuously true assertion reduces test value.

Line 304 asserts that id 99 is not in the result, but no ticket type with id 99 was created in this test. The assertion will always pass regardless of the actual filtering behavior.

To strengthen this test, either:

1. Remove the misleading assertion about id 99 (the test still proves the strategy returns results via the id 30 check), or
2. Add a WithPromoCode ticket type to the promo code mock and verify the strategy correctly excludes it when no promo code is provided.

♻️ Suggested fix — remove misleading assertion

         $ids = array_map(fn($tt) => $tt->getId(), $result);
         // Audience_All type IS returned (non-vacuous: proves the strategy produces results)
         $this->assertContains(30, $ids, 'Audience_All ticket type should be returned without a promo code');
-        // WithPromoCode type (id 99) is NOT returned — it only lives in promo_code->getAllowedTicketTypes()
-        $this->assertNotContains(99, $ids, 'WithPromoCode ticket types should not be returned without a promo code');

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/Unit/Services/DomainAuthorizedPromoCodeTest.php` around lines 291 -
305, The assertion is vacuous because no ticket type with id 99 exists in this
test; update the testWithPromoCodeAudienceNoPromoCodeNotReturned to actually
create a "WithPromoCode" ticket type (e.g., via buildMockTicketType(99,
SummitTicketType::Audience_Promo) or similar) and attach it only to a mocked
promo code's getAllowedTicketTypes() so that
RegularPromoCodeTicketTypesStrategy($summit, $member, null)->getTicketTypes()
has both id 30 and id 99 available in the source data and you can assert that 30
is returned while 99 is not; alternatively, if you prefer the simpler change,
remove the misleading assertNotContains(99, $ids) line entirely to avoid the
vacuous check.

app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationDiscountCode.php (1)

53-60: Remove this no-op override or clarify intent with accurate documentation.

The parent SummitRegistrationPromoCode::addAllowedTicketType() contains no audience-based restrictions—it simply adds the ticket type to the collection. This override merely delegates to the parent without any custom logic, making it redundant. The docblock's claim that it "allows any ticket type regardless of audience value" is misleading, as the parent already permits any ticket type. Either remove the override or, if it serves a semantic purpose in the inheritance hierarchy, update the docblock to accurately reflect that.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/Models/Foundation/Summit/Registration/PromoCodes/DomainAuthorizedSummitRegistrationDiscountCode.php`
around lines 53 - 60, The addAllowedTicketType method in
DomainAuthorizedSummitRegistrationDiscountCode is a redundant no-op that only
calls parent::addAllowedTicketType (the parent SummitRegistrationPromoCode
already permits any ticket type); either remove this override entirely to avoid
dead code, or if you want an explicit semantic override, keep the method but
replace the misleading docblock with a concise note like "Intentional
passthrough to parent to signal inherited behavior" and ensure the method body
remains a direct parent call (referencing
DomainAuthorizedSummitRegistrationDiscountCode::addAllowedTicketType and
SummitRegistrationPromoCode::addAllowedTicketType).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/Services/Model/Imp/SummitPromoCodeService.php (1)

1031-1054: Batch per-code usage lookups for discovery.

getDiscoverableByEmailForSummit() loads the candidate codes, and then each domain-authorized result triggers another getTicketCountByMemberAndPromoCode() call. On a summit with many matching codes, this becomes a 1+N query pattern on the registration hot path. Consider a repository method that returns usage counts keyed by promo-code ID for the member.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Services/Model/Imp/SummitPromoCodeService.php` around lines 1031 - 1054,
The loop in SummitPromoCodeService uses getDiscoverableByEmailForSummit() then
calls getTicketCountByMemberAndPromoCode() per code, causing 1+N queries; add a
repository method such as getTicketCountsByMemberAndPromoCodes($member, array
$promoCodeIds) that returns a map promoCodeId=>usedCount, call it once after
retrieving $codes, then in the foreach over $codes (same loop referencing
IDomainAuthorizedPromoCode, getQuantityPerAccount,
setRemainingQuantityPerAccount) read the used count from that map to decide
exhaustion and set remaining per-account quantity instead of making per-code
repository calls.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes