- Shipped
- September 3, 2026 at 3:37 AM UTC
- Author
- Kamo
- Commit
- 6382788
Comping an account granted the plan and nothing else. provisionCompSubscription copied plan, seats, cycle, source and status onto the AccountSubscription and never touched active_addon_codes — the column both MailboxBillingController and PbxBillingController read entitlement from. An order comping Enterprise plus "3rd Party Email Integration" and "3rd Party PBX Integration" therefore provisioned Enterprise alone, and the organization was told on its own email screen that the provider it had just been given "Requires the 3rd Party Integration add-on". The identity of the add-ons was already gone by then. createOrder built its line items out of PriceCalculationLineItemDTO, which carried a description, an amount and a recurring flag — no reference of any kind — and classified them by **************** So an order recorded THAT two add-ons had been sold and never WHICH two, leaving reference_id and reference_code null on every ADDON row in the estate. Carry the identity through instead: the quote line names the add-on's uid and catalog code, createOrder persists both, and SubscriptionOrderAddons turns an order's lines into the codes it grants. That last step is a plain static function over the line items and the market catalog, deliberately free of Spring — this bug survived because the logic lived inline in a method needing a dozen Docstors to call, so nothing exercised it. Orders written before this carry only an English label, so codesOf falls back to matching the add-on's name against the catalog. Without it every order already placed would provision nothing and the only remedy would be to re-key it. Also log the three silent returns in provisionCompSubscription. A comp with no customer member, no billing account or no market returned quietly and the operator got "Order approved" back, which is exactly why this was invisible until a customer complained.