fix: cp-7.57.0 prevent unnecessary reward navigation on account change#21264
Merged
Conversation
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
jbblanc
approved these changes
Oct 16, 2025
EugeniyBykov
approved these changes
Oct 16, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When you reinstalled the app and reimported an SRP where the first account/group was tied to the rewards program, you wouldn't see the rewards gtm modal as its logic wouldn't trigger. In the same session, when switching to an account that wasn't tied to the rewards program yet, the gtm modal would trigger a navigation to the onboarding/gtm modal but then we'd detect that there was opted in for another/other accounts (i.e. primary) and the rewards dashboard would be seen.
To prevent this, in the logic that spawns the gtm modal, as soon as we detect a
subscriptionId, we set the gtm modal seen storage prop to true, preventing it to be spawned/navigated to when changing an account that had nosubscriptionId.Minor extra fix; as we're moving ahead with prod readiness, we are switching the geo check URI to prod.
Changelog
CHANGELOG entry: null
Related issues
Fixes: #21252
Manual testing steps
Note
Marks the rewards intro modal as seen when a subscription exists and on intro step mount to prevent unwanted navigation, simplifies the intro modal, and forces the geolocation service to use the PROD URL; tests updated accordingly.
REWARDS_GTM_MODAL_SHOWNpersistence toOnboardingIntroStep(set on mount) and simplifyRewardsIntroModalto be presentational only.useRewardsIntroModal, ifsubscriptionIdexists, setREWARDS_GTM_MODAL_SHOWNtotrueand skip navigation.RewardsController:isOptInSupportedcheck.RewardsDataService.fetchGeoLocationnow always usesGEOLOCATION_URLS.PROD.OnboardingIntroStepanduseRewardsIntroModal.Written by Cursor Bugbot for commit 63407dd. This will update automatically on new commits. Configure here.