[HOLD for payment 2024-11-01] [$250] TransitionOD-ND - When disabling tax in OD, ND "page not Found", "Back" takes to WS selection

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.46-3 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5053996 Issue reported by: Applause - Internal Team

Action Performed:

1. Open ND App
2. Create a WS
3. Log in as the same user in OD
4. In OD Click on Workspaces
5. Select the same WS as in ND
6. In OD go to WS settings and enable Tax
7. In ND go to WS settings, on LHP click on Tax icon 8.With Tax page open in ND, navigate to OD and disable Tax option

Expected Result:

In ND the user is navigated to the LHP/WS editor page

Actual Result:

The user is shown "Ops...It's not here" page, the "Back" button takes you back to the WS selection page(User leaves the WS editor page)

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/f79895d5-f082-4c99-9529-3921efb87aa1

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021845793851841023680
• Upwork Job ID: 1845793851841023680
• Last Price Increase: 2024-10-14

Issue Owner

Current Issue Owner: @sonialiap

[melvin-bot[bot]]

Triggered auto assignment to @sonialiap (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[lanitochka17]

@sonialiap FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[bernhardoj]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Going back from not found tax page leads to workspace list page.

What is the root cause of that problem?

When we disable the tax page, it's expected that a full screen not found page will show. The reason pressing back leads to the workspace list page is because a Navigation.dismissModal is called, which closes the workspace details page.

https://github.com/Expensify/App/blob/5d25b40eab1416d2d67624a376099853a2b6af86/src/pages/workspace/AccessOrNotFoundWrapper.tsx#L88-L97

What changes do you think we should make in order to solve the problem?

shouldShowFullScreenFallback is true if the feature is disabled or the policy is not accessible. https://github.com/Expensify/App/blob/5d25b40eab1416d2d67624a376099853a2b6af86/src/pages/workspace/AccessOrNotFoundWrapper.tsx#L169

I think we should only close the workspace detail page if the policy is not accessible. To do that, we need to pass both isFeatureEnabled and isPolicyNotAccessible to PageNotFoundFallback and remove the shouldShowFullScreenFallback props and instead, add it as a local variable in PageNotFoundFallback.

isFeatureEnabled={isFeatureEnabled}
isPolicyNotAccessible={isPolicyNotAccessible}

Then, in PageNotFoundCallback, https://github.com/Expensify/App/blob/5d25b40eab1416d2d67624a376099853a2b6af86/src/pages/workspace/AccessOrNotFoundWrapper.tsx#L88-L98

only use dismissModal if the policy is not accessible. If the feature is disabled, then we will just go back.

const shouldShowFullScreenFallback = !isFeatureEnabled || isPolicyNotAccessible;
onBackButtonPress={() => {
    if (isPolicyNotAccessible) {
        Navigation.dismissModal();
        return;
    }
    Navigation.goBack(policyID && !isMoneyRequest ? ROUTES.WORKSPACE_PROFILE.getRoute(policyID) : undefined);
}}

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~021845793851841023680

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[mananjadhav]

Got assigned today. Will review the proposal.

[mananjadhav]

I think @bernhardoj's proposal looks good. We'll need to check if it exists for other pages such as "Tags", etc.

🎀 👀 🎀 C+ reviewed.

[melvin-bot[bot]]

Triggered auto assignment to @madmax330, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[bernhardoj]

PR is ready cc: @mananjadhav

[mananjadhav]

Thanks, I'll review and test by tomorrow.

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.53-1 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/50801

If no regressions arise, payment will be issued on 2024-11-01. :confetti_ball:

For reference, here are some details about the assignees on this issue:

• @mananjadhav requires payment through NewDot Manual Requests
• @bernhardoj requires payment through NewDot Manual Requests

[melvin-bot[bot]]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [ ] [@mananjadhav] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@mananjadhav] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [ ] [@mananjadhav] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [ ] [@mananjadhav] Determine if we should create a regression test for this bug.
• [ ] [@mananjadhav] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [x] [@sonialiap] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: https://github.com/Expensify/Expensify/issues/441368

[melvin-bot[bot]]

Payment Summary

Upwork Job

• Reviewer: @mananjadhav owed $250 via NewDot
• Reviewer: @bernhardoj owed $250 via NewDot

BugZero Checklist (@sonialiap)

• [ ] I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• [ ] I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1845793851841023680/hired)
• [ ] I have paid out the Upwork contracts or cancelled the ones that are incorrect
• [ ] I have verified the payment summary above is correct

[mananjadhav]

I tried to find an offending PR for this one but I couldn't. We refactored this code quite a bit but I think we should add a regression test for this.

@sonialiap Here's the regression test proposal and this one is ready for payout.

Prerequisite: logged in as the same user in 2 tabs/devices.

1. Open any workspace > More features > Enable taxes.
2. Open Taxes.
3. From the other devices, disable the taxes from the More features page.
4. Back to the first device, verify a not found page is shown.
5. Press the back button.
6. Verify you are navigated back to the WS settings page.

[bernhardoj]

Requested in ND.

[sonialiap]

Payment summary:

• @mananjadhav $250 via NewDot
• @bernhardoj $250 via NewDot

[JmillsExpensify]

$250 approved for @bernhardoj

[garrettmknight]

$250 approved for @mananjadhav