Validation Flow¶

Flow Diagram¶

graph TB
    A["HTTP Request"] --> B["Form Request\nauthorize() + rules()"]
    B -->|invalid| C["422 JSON\nor redirect (CartItemRequest)"]
    B -->|valid| D["Controller"]
    D --> E["WithData trait\nspatie/laravel-data DTO\nSecond validation layer"]
    E --> F["Action / Manager"]
    F --> G["Custom Rule Classes\nBusiness logic validation\ne.g. BuyableRule, PurchaseLimitRule"]
    G -->|fail| H["Validation exception\nredirect or 422"]
    G -->|pass| I["DB operation"]

Purpose¶

Three-layer validation: HTTP boundary (Form Requests), typed DTO conversion (spatie/laravel-data), and business rule validation (custom Rule classes). Purchase limit enforcement runs at both cart-add and order-placement.

Layer 1: Form Requests¶

33 Form Request classes across web and admin surfaces.

Path: app/Http/Requests/

Web Requests¶

Admin Requests¶

15 Product requests, 4 Order requests, 1 Membership, 1 Sales.

Note: CartItemRequest overrides failedValidation() to redirect back to cart (not 422 JSON) on ProductVariationBuyableRule / BuyableRule failures.

Order Validation Rules¶

OrderRequest — app/Http/Requests/Web/Order/OrderRequest.php¶

Applied on order placement (orders.store) and order update.

prepareForValidation: On orders.store, merges previously stored session('order_address') into the request so address fields survive the confirmation step.

passedValidation: Enriches the request with computed order fields before it reaches the controller: - Converts orderer_birthdate array to a Carbon instance - Sets status → OrderStatusEnum::OPEN - Computes subtotal, tax, shipping_charge, shipping_charge_tax, total_amount from current cart items

OrderRetryRequest — app/Http/Requests/Web/Order/OrderRetryRequest.php¶

Applied when retrying a failed payment.

Cart Validation Rules¶

CartItemRequest — app/Http/Requests/Web/Cart/CartItemRequest.php¶

Applies on add-to-cart (POST) and cart update (PATCH). Uses WithData trait — validated data is cast to CartItemDTO.

Purchase limit inline closure on product_variation_id: Iterates all purchaseLimits on the product and runs CartManager::initializePurchaseLimit() for each:

• PER_ORDER — checked inline: fails if quantity exceeds the product's purchase_limit. On PATCH for multi-shot CKC variations, also sums other shot-type cart items for the same variation and fails if combined total exceeds purchase_limit.
• PER_USER, PER_DATE, PER_MEMBER — delegated to PurchaseLimitRule providers; fail if the provider's checkLimit() returns true.

Failure redirect: On POST, if product_variation_id fails via closure, ProductVariationBuyableRule, or ProductIfIsLotteryRule, failedValidation() redirects to orders.cart with errors instead of returning a 422.

ProductVariationBuyableRule — app/Rules/Cart/ProductVariationBuyableRule.php¶

Checks buyability at the point of adding to cart (POST only).

Lottery Validation Rules¶

LotteryRequest — app/Http/Requests/Web/Lottery/LotteryRequest.php¶

Applied when updating/deleting a lottery application. Uses WithData → LotteryDTO.

LotteryCartRequest — app/Http/Requests/Web/LotteryCart/LotteryCartRequest.php¶

Applied when adding/updating a lottery cart item. Uses WithData → LotteryCartItemDTO.

On PATCH, product_variation_id is resolved from the route's LotteryCartItem model rather than the request body.

CanApplyVariationRule — app/Rules/Lottery/CanApplyVariationRule.php¶

Used in LotteryRequest (update flow).

applyCount* values are computed by ProductManager and adjusted by subtracting the current application's quantity_applied so editing does not double-count the user's existing application.

TotalProductLimit — app/Rules/Lottery/TotalProductLimit.php¶

Prevents the total quantity across all variations of the same product in the lottery cart from exceeding $product->purchase_limit.

(quantity being added) + (sum of other variations' qty in lottery cart) <= product.purchase_limit

Fails with cart.purchase_limit.per_order.

MaxVariationQtyLimit — app/Rules/LotteryCart/MaxVariationQtyLimit.php¶

Prevents quantity for a single variation from exceeding the variation's stock ($variation->quantity).

Fails with lottery.apply_limit.

ApplyLotteryRule — app/Rules/LotteryCart/ApplyLotteryRule.php¶

Main lottery cart quantity rule. Runs two checks:

1. Purchase limit providers (via LotteryCartManager::initializeApplyLimit):

Iterates product->purchaseLimits and delegates to the matching provider. All limit types set quantity; providers check against their stored/cart counts.

2. purchase_limit_per_date inline check (if set):

quantity + (other variations' lottery cart qty for same product) + (confirmed lottery qty for same product+date) <= purchase_limit_per_date

This cross-checks lottery cart items with already-confirmed Lottery records filtered by product_id and ckc_start_date. Fails with lottery.purchase_limit.per_date.

Layer 2: DTO Validation (spatie/laravel-data)¶

13 DTO classes across modules. 6 Form Requests use the WithData trait — DTOs carry inline spatie validation annotations.

Key DTOs with inline validation: - UserEmailDTO — email format + uniqueness - UserPasswordDTO — password rules - OrderDTO, CartItemDTO, LotteryCartItemDTO, ProductDTO, ProductVariationDTO etc.

Path: app/Modules/*/DTOs/

Layer 3: Custom Rule Classes (21 rules)¶

Path: app/Rules/

Cart Rules¶

Chekicha CSV Rules (6)¶

Lottery Rules¶

LotteryCart Rules¶

Order Rules¶

Product Rules¶

Global¶

Purchase Limit Enforcement¶

Standard Cart (physical/digital products)¶

Two checkpoints prevent race conditions:

Cart add (POST/PATCH)
  └─ CartItemRequest inline closure
       ├─ PER_ORDER  → quantity vs product.purchase_limit (+ CKC multi-shot cross-check on PATCH)
       ├─ PER_USER   → PurchaseLimitRule provider
       ├─ PER_DATE   → PurchaseLimitRule provider
       └─ PER_MEMBER → PurchaseLimitRule provider
     Also on POST: ProductVariationBuyableRule (availability + stock)

Order placement (orders.store)
  └─ BuyableRule (per cart item)
       ├─ stock recheck: variation.quantity >= quantity
       ├─ PER_USER   → purchased_count + quantity <= purchase_limit_per_user
       ├─ PER_DATE   → purchased_count + cart_count <= purchase_limit_per_date
       └─ PER_MEMBER → purchased_count + cart_count <= purchase_limit_per_member
       (PER_ORDER is skipped at order placement — already enforced at cart add)

Lottery Cart¶

Lottery cart add/update (POST/PATCH)
  └─ LotteryCartRequest
       ├─ POST only: withinLotteryPeriod() check on product_variation_id
       └─ quantity rules:
            ├─ ApplyLotteryRule → limit providers (PER_ORDER, PER_USER, PER_DATE, PER_MEMBER)
            │                   + inline PER_DATE cross-check vs confirmed Lottery records
            ├─ TotalProductLimit → total across all variations vs product.purchase_limit
            └─ MaxVariationQtyLimit → quantity vs variation.quantity (stock cap)

Lottery application update (LotteryRequest)
  └─ CanApplyVariationRule
       ├─ quantity vs variation.quantity
       └─ fetchCanApplyVariationCount() respects applied/date/member limits minus current application

Limit types (from PurchaseLimitTypeEnum): PER_ORDER, PER_USER, PER_DATE, PER_MEMBER.

Error Response Formats¶

Failure Paths¶