[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] Workspace features-User not returned to WS settings after enabling Accounting in more features

[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: 1.4.77
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Issue found when executing PR #42026

Action Performed:

1. Open the app and log in
2. Create a new workspace
3. Navigate to the workspace settings
4. Open More features
5. Enable Accounting

Expected Result:

User is returned to workspace settings, the Accounting feature is highlighted

Actual Result:

User is not returned to the workspace settings. The Accounting feature is not removed immediately after disabling

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6495362_1717004098448.video_2024-05-29_13-34-27.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @bfitzexpensify / @kadiealexander

Issue Owner

Current Issue Owner: @bfitzexpensify / @kadiealexander

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (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]

@bfitzexpensify 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

[Nodebrute]

Proposal

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

Workspace features-User not returned to WS settings after enabling Accounting in more features

What is the root cause of that problem?

It's because we are not navigating after enabling policy connections

App/src/libs/actions/Policy/Policy.ts

Lines 3668 to 3669 in ee1196d

	API.write(WRITE_COMMANDS.ENABLE_POLICY_CONNECTIONS, parameters, onyxData);
	}

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

We can add after this

App/src/libs/actions/Policy/Policy.ts

Lines 3668 to 3669 in ee1196d

	API.write(WRITE_COMMANDS.ENABLE_POLICY_CONNECTIONS, parameters, onyxData);
	}

    if (enabled && getIsNarrowLayout()) {
        navigateWhenEnableFeature(policyID);
    }

What alternative solutions did you explore? (Optional)

[bfitzexpensify]

@allroundexperts looks like this might have been caused by #42026 - mind checking?

[Nodebrute]

@bfitzexpensify Hey, It's not a regression from this #42026

[melvin-bot]

Triggered auto assignment to @kadiealexander (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.

[bfitzexpensify]

Assigning a second BZ team member to this one while I head OOO from later on today until Tuesday June 11th.

@kadiealexander Next steps:

• get confirmation from [HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] Workspace features-User not returned to WS settings after enabling Accounting in more features #42789 (comment) if this can be handled as a regression related to fix: re-add finetunings #42026
• if not, open this up for external proposals

[Nodebrute]

@kadiealexander Hey, this isn't a regression. We never implemented the feature to navigate after enabling accounting.

[kadiealexander]

Thanks @Nodebrute! I'd like to get confirmation from someone who worked on the original issue, @sobitneupane could you please confirm since you were C+ on the original PR?

[sobitneupane]

@allroundexperts Looks like #39214 issue was not addressed in #42026 PR.

[allroundexperts]

Yep, you're correct @sobitneupane. I'll create a PR for this.

[allroundexperts]

PR: #43043

[melvin-bot]

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

[thienlnam]

Merged, it looks like we forgot to add this in a previous PR

[kadiealexander]

@thienlnam do you think anyone is due payment here?

[thienlnam]

Doesn't look like it since this was a feature that was missed as part of a previous PR - looks like we're good to close

[melvin-bot]

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

[melvin-bot]

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

• fix: add redirect when policy connection is enabled #43043

If no regressions arise, payment will be issued on 2024-06-18. 🎊

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

• @allroundexperts requires payment through NewDot Manual Requests

[melvin-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:

• [@allroundexperts] The PR that introduced the bug has been identified. Link to the PR:
• [@allroundexperts] 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:
• [@allroundexperts] 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:
• [@allroundexperts] Determine if we should create a regression test for this bug.
• [@allroundexperts] 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.
• [@bfitzexpensify / @kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

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

• fix: add redirect when policy connection is enabled #43043

If no regressions arise, payment will be issued on 2024-06-20. 🎊

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

• @allroundexperts requires payment through NewDot Manual Requests

[melvin-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:

• [@allroundexperts] The PR that introduced the bug has been identified. Link to the PR:
• [@allroundexperts] 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:
• [@allroundexperts] 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:
• [@allroundexperts] Determine if we should create a regression test for this bug.
• [@allroundexperts] 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.
• [@bfitzexpensify / @kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: