[$250] Rules - App returns to not here page after disabling Rules

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.0.25-0
Reproducible in staging?: Y
Reproducible in production?: N
Email or phone of affected tester (no customers): applausetester+kh050806@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• Tags feature is disabled.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules.
3. Click tags.
4. On More features page, disable Rules.
5. Tap app back button.

Expected Result:

App will return to workspace editor page.

Actual Result:

App returns to not here page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6583732_1724720418319.1724720180304_Screen_Recording_20240827_085612_New_Expensify.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c846999c3a53187c
• Upwork Job ID: 1828377043023943988
• Last Price Increase: 2024-08-27
• Automatic offers:
• brunovjk | Reviewer | 103700946

Issue Owner

Current Issue Owner: @brunovjk

[melvin-bot]

Triggered auto assignment to @Julesssss (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[IuliiaHerets]

We think that this bug might be related to #wave-control

[daledah]

Proposal

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

App returns to not here page.

What is the root cause of that problem?

When press tags, we navigate to workspace features page if tags are not enabled:

App/src/pages/workspace/rules/IndividualExpenseRulesSection.tsx

Lines 53 to 60 in 1739e7c

	const handleOnPressTagsLink = () => {
	if (policy?.areTagsEnabled) {
	Navigation.navigate(ROUTES.WORKSPACE_TAGS.getRoute(policyID));
	return;
	}
	Navigation.navigate(ROUTES.WORKSPACE_MORE_FEATURES.getRoute(policyID));
	};

Later when Rules are disabled, we press back and get navigated back again to Rules page, which was disabled, causing not found page to show.

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

Before navigating to more features page, pop the current Rules page out of the navigation stack by Navigation.goBack.

By that, we would navigate back to the workspace settings page.

[melvin-bot]

📣 @praveenking945! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[mkhutornyi]

workspaceRules is in beta. Not deploy blocker

[Julesssss]

workspaceRules is in beta. Not deploy blocker

Agree.

[melvin-bot]

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

[melvin-bot]

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

[trjExpensify]

Bringing it to the attention of the team in thread: https://expensify.slack.com/archives/C06ML6X0W9L/p1724762281982389?thread_ts=1724709178.360259&cid=C06ML6X0W9L

[WojtekBoman]

Hi! I'm going to work on that :)

[melvin-bot]

📣 @brunovjk 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[WojtekBoman]

I have an idea how we can solve this issue:

I can check in navigation state if the user has access to the page which is displayed after going back. If the page's feature is disabled, this page will be skipped. But in this case I can't change the browser back button behaviour because I can't modify the browser's history, it would be fixed only for the app and android native back buttons.
The app back button:

Screen.Recording.2024-08-27.at.16.47.26.mov

The browser back button:

Screen.Recording.2024-08-27.at.16.48.23.mov

This case is also reproducible on other pages connected with features that can be enabled, here's an example:

Screen.Recording.2024-08-27.at.16.52.31.mov

Please let me know if this solution is ok for you

[marcaaron]

@Julesssss feel free to hand this off to me if you'd like as it's related to OldDot Rules migration

[Julesssss]

Sure, thanks

[brunovjk]

Hi @WojtekBoman, Thanks for looking into this issue! Your proposed solution for handling the navigation state and preventing users from landing on a disabled page seems solid. It might also be beneficial to explore a solution for the browser back button issue, if feasible. @marcaaron, what are your thoughts on this approach?

[marcaaron]

@trjExpensify do you know if we have a standard way of handling this sort of navigation pattern. It sort of makes sense to me that if a page becomes inaccessible, but exists in the browser history that we'd be aright to just show the "not found" page. It's not like the user is trapped there forever. Feels kind of edge case to me and unsure if it warrants doing any complex manipulation of the history stack.

[trjExpensify]

I think our standard is to just show the not found guy. I agree it's edge case territory. 👍

[marcaaron]

Ok, I'm gonna close this out.