Fix operator precedence bug in isMobileStaticRecalibrationApplicable causing unnecessary mobile schedule lookups

The isMobileStaticRecalibrationApplicable computed property in schedule.vue had
incorrect operator precedence that made it far too permissive. Due to misplaced
parentheses, the condition evaluated as:

  (displayMSR && RECAL_FEE_PART && enableMSRSplitPay) || isCashItacNoComp || isInsurable

This meant ANY cash/ITAC/NoComp order OR any order with an insurable mobile fee
part would be considered MSR-applicable, regardless of whether displayMSR was
enabled or the mobile fee part was actually the RECAL MOBILE fee.

As a result, isServiceableMobile could return true even when the backend
explicitly set isRecalibrationServiceableMobile to false, causing:
- Mobile schedule API calls for orders that cannot be serviced mobile
- Mobile appointment type being offered when it should not be
- Incorrect UI state on the schedule page

The fix aligns schedule.vue with the correct logic already present in
service-location.vue and service-location-june-2025.vue:

  displayMSR && RECAL_FEE_PART && (enableMSRSplitPay || isCashItacNoComp || isInsurable)

This ensures all three base conditions (MSR experiment enabled, correct fee part,
and payment eligibility) must be met before MSR is considered applicable.

Co-authored-by: Mark Harris <mark.harris@safelite.com>
This commit is contained in:
Cursor Agent 2026-04-09 19:25:47 +00:00
parent 292b626267
commit 848e74f6ec
No known key found for this signature in database

View file

@ -705,11 +705,9 @@ export default {
},
isMobileStaticRecalibrationApplicable() {
return (
(this.displayMSR &&
this.mobileFeePart?.partNumber == partNumberStrings.MOBILE_STATIC_RECAL_FEE &&
this.enableMSRSplitPay) ||
this.isCashItacNoComp ||
this.mobileFeePart?.isInsurable
this.displayMSR &&
this.mobileFeePart?.partNumber == partNumberStrings.MOBILE_STATIC_RECAL_FEE &&
(this.enableMSRSplitPay || this.isCashItacNoComp || this.mobileFeePart?.isInsurable)
);
},
displayMSR() {