6f09cd3e78
The schedule.vue isMobileStaticRecalibrationApplicable computed property had
broken operator precedence, making isCashItacNoComp and mobileFeePart?.isInsurable
standalone OR branches instead of being gated behind displayMSR and the
MOBILE_STATIC_RECAL_FEE part check.
This meant any self-pay (cash/ITAC/NoComp) order always evaluated
isMobileStaticRecalibrationApplicable as true, regardless of whether the
DISPLAY_MSR experiment was enabled or whether the order even had a
MOBILE_STATIC_RECAL_FEE part. In turn, isServiceableMobile returned true
even when isRecalibrationServiceableMobile === false (recalibration cannot
be done mobile), causing GET_MOBILE_TIME_SLOTS to be fetched for orders
where mobile service should not be offered.
Fix aligns the logic with service-location.vue:
- require displayMSR AND mobileFeePart.partNumber === MOBILE_STATIC_RECAL_FEE
AND (isCashItacNoComp OR mobileFeePart.isInsurable)
Also removes the now-unused enableMSRSplitPay computed property.
Adds unit tests covering isMobileStaticRecalibrationApplicable and
isServiceableMobile for the recal-cannot-be-done-mobile scenario.
Co-authored-by: Mark Harris <mark.harris@safelite.com>
|
||
|---|---|---|
| playwright-tests | ||
| public | ||
| src | ||
| temp | ||
| .gitattributes | ||
| .gitignore | ||
| .prettierrc | ||
| azure-pipelines-automated-testing.yml | ||
| azure-pipelines.yml | ||
| babel.config.js | ||
| Dockerfile.playwright | ||
| environment-variables.js | ||
| jest.config.js | ||
| jsconfig.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| vue.config.js | ||
| vue.release.config.js | ||
Fix My Glass Vue Project
This Repository is for Fix My Glass front end Vue and documentation associated with it.
Routing
We are using Vue Router 4.x for our front end routing. We are using a runtime dynamic routing solution. Some more information about dynamic routing can be found on the official Vue Router documentation.
Next() - Is a function that is native to Vue Router in which we call in order to send the user where want them to go based on some logic we have. You can read more about Navigation Guards and the Next() function on the Vue Router documentation.
GetRouteInfoFromPageName(PageName) - This method typically takes the query string value of fmgPage and passes it into a call to our Content Service. The service will pull information on the page; matching page name passed to page name in our Cms. If we have a match, we will compile the route information and send it to our router to process. If we do not have a that page in our Cms, the user will be served back a 404 page while retaining the structure.
GoToFunnelStartOn404(next) - When a user tries to go to a page that doesn't exist in the CMS, they will be put back to the 'Start' of the funnel which is whatever page is marked as the homepage on Sitefinity.