Fix Submit plan welcome modal: navigate to existing Submit workspace and remove double bottom safe-area padding#96459
Conversation
Fixes two issues reported against the Submit plan welcome modal: - Navigate to the existing Submit workspace instead of Home when an already-onboarded user confirms the modal while an editable Submit workspace already exists (Expensify#96123). The fallback is scoped to callers that skip onboarding completion so the onboarding flows are untouched. - Stop applying the bottom safe-area inset twice on Android by letting CenteredModalLayout consumers opt out of the wrapper inset when their content (FeatureTrainingContent's ScrollView) already includes it, removing the empty band under the modal buttons (Expensify#96121).
|
@mkhutornyi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
this is ready for review @hungvu193 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0504da1c11
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ); | ||
| const [hasEditableGroupPolicy] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: groupPolicySelector}); | ||
| const existingSubmitPolicyIDSelector = useMemo( | ||
| () => (policies: OnyxCollection<Policy>) => Object.values(policies ?? {}).find((policy) => isSubmitPolicy(policy) && canEditWorkspaceSettings(policy))?.id, |
There was a problem hiding this comment.
Pass the login when resolving the Submit workspace
When the policy collection has a partially loaded Submit policy without top-level role (the case canEditWorkspaceSettings(policy, login) supports via employeeList[currentUserEmail].role), this selector returns undefined even though the user can edit the workspace. For an already-onboarded modal invocation that skips creation because another editable group policy is present, the fallback still passes no policy ID and navigates Home instead of the existing Submit workspace. Pass currentUserEmail here and include it in the memo dependencies.
Useful? React with 👍 / 👎.
joekaufmanexpensify
left a comment
There was a problem hiding this comment.
Fixing Deploy Blockers
Explanation of Change
Fixes the two bugs reported against the Submit plan welcome modal introduced in #95099.
1. Home page opens after clicking "Get the free plan" when a Submit workspace already exists (#96123)
When the modal is opened again (via the
/workspaces/submit-plan-welcomedeep link) after a Submit workspace was already created,useAutoCreateSubmitWorkspaceskips workspace creation (hasEditableGroupPolicyistrue) and falls back toonboardingPolicyID, which is empty for an already-onboarded user.navigateToSubmitWorkspaceAfterOnboardingthen receivesundefinedand lands on Home.Fix: add a second policy-collection selector that resolves the ID of the user's existing editable Submit workspace, and use it as the navigation fallback. The fallback is scoped to already-onboarded callers (
shouldCompleteOnboarding === false, i.e. only the welcome modal): the three onboarding call sites (BaseOnboardingPurpose,BaseOnboardingPersonalDetails,BaseOnboardingWorkspaces) keep their exact current behavior, and thecompleteOnboardingpayload is untouched, so there is no regression surface for the onboarding flows.2. Free plan modal shows empty space at the bottom on Android (#96121)
The bottom safe-area inset was applied twice on devices with a bottom inset (e.g. Android gesture bar): once by
CenteredModalLayout's content wrapper (viauseBottomSafeSafeAreaPaddingStyle, which adds the inset on top of the modal's zeroedpb0), and once byFeatureTrainingContent's ScrollView content padding (getScrollableFeatureTrainingModalStyles=pb5 + inset). The result was apb5 + 2×insetempty band under the buttons — invisible on web where the inset is 0.Fix: add an
addBottomSafeAreaPaddingprop (defaulttrue) toCenteredModalLayoutso consumers whose children already handle the inset can opt out, and passfalsefromSubmitPlanWelcomeModal. Existing consumers are unaffected by default. Note:MigratedUserWelcomeModal,AutoSubmitModal, andChangePolicyEducationalModaluse the same pattern and share this latent double-inset; they can opt in via the same prop in a follow-up once verified on device.Also adds two unit tests covering the navigation fallback (modal path navigates to the existing Submit workspace; onboarding path behavior unchanged).
Fixed Issues
$ #96121
$ #96123
PROPOSAL:
Tests
#96123 — navigation to existing Submit workspace:
SUBMIT_2026beta for your account.https://dev.new.expensify.com:8082/workspaces/submit-plan-welcome.#96121 — no empty space at the bottom (Android):
https://dev.new.expensify.com:8082/workspaces/submit-plan-welcome.Offline tests
QA Steps
Same as tests.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Screen.Recording.2026-07-19.at.18.00.48.mov
Android: mWeb Chrome
iOS: Native
Screen.Recording.2026-07-19.at.17.58.25.mov
iOS: mWeb Safari
Screen.Recording.2026-07-19.at.17.59.46.mov
MacOS: Chrome / Safari
Screen.Recording.2026-07-19.at.17.52.32.mov