Include tier prices in catalog rule indexer to prevent rule from raising effective price

[ddevallan]

Description

The catalog rule indexer (RuleProductsSelectBuilder::buildSelect()) computed default_price from the regular product price only — tier prices were completely ignored.

When a catalog rule calculates a discounted price that is still higher than an existing tier price, the indexed rule price is used instead of the tier price, effectively raising the visible price for customers who qualify for both.

Example: Regular $100 · Tier $30 (all groups) · 50% rule → $50 without fix. With fix: LEAST($30,$100)=$30 → 50%=$15 ≤ $30 ✓

Fix

Added two LEFT JOINs on catalog_product_entity_tier_price for website-specific and global (website_id=0) tier prices, using OR all_groups = 1 to handle tier prices that apply to all customer groups. default_price is wrapped in LEAST():

LEAST(
    IFNULL(price_tier0.value, pp_default.value),  -- global tier or regular
    IFNULL(price_tier.value, pp_default.value),    -- website tier or regular
    IFNULL(pp_website.value, pp_default.value)     -- regular price
)

⚠️ Known limitations

qty = 1 only — intentional design decision

Only tier prices with qty = 1 are joined. This is deliberate: the catalog rule indexer's default_price represents the single-unit display price shown in product listings.

Consider a product with regular price $100, a qty ≥ 5 tier price of $20, and a 50% rule. Including the qty=5 tier in LEAST() would give $10 as the indexed rule price — but $10 only applies when buying 5+ units. A customer buying 1 unit would see $10 in listings and pay $50 at checkout. This would be misleading.

qty = 1 tier prices are semantically different: they apply from the very first unit (effectively group-specific prices) and are safe to include in the single-unit price calculation. The integration test testReindexFullTierPriceForQtyAboveOneIsNotConsideredByIndexer explicitly documents this behavior.

Other limitations

• Performance — two additional LEFT JOINs on the indexer SELECT will slightly increase full reindex time on large catalogs
• Duplicate rows edge case — if a product has both an all_groups = 1 tier AND a specific-group tier for the same website and qty=1, both match the JOIN and may produce duplicate result rows

Test results

Unit tests (3):

 ✔ Build select joins tier prices for website
 ✔ Build select includes tier prices in least expression
 ✔ Build select tier join includes all groups condition
OK (3 tests, 16 assertions)

Integration tests — full scenario matrix (6):

Scenario	Description	Result
All-groups global tier caps rule	Tier $30 < rule $50 → rule price ≤ $30	✅
Rule wins when lower than tier	Tier $80 > rule $40 → rule price still ≤ $80	✅
Specific customer group tier	Only group 1 has tier — only group 1 is capped	✅
Website-scoped tier (price_tier JOIN)	Tier on website_id=1 respected	✅
Global + website tier — LEAST picks lower	$40 global vs $20 website → $20 wins	✅
Volume discount (qty>1) — documents known limitation	qty=5 tier ignored; rule applies to regular price	✅

OK (6 tests, 57 assertions) in 12s

Existing indexer tests — no regression (3):

 ✔ Reindex full · ✔ Reindex by id · ✔ Reindex by ids
OK (3 tests, 7 assertions)

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated — N/A
• All automated tests passed successfully (all builds are green)