[Due for payment 2025-07-10] Remove the duplicate Upgrade modal in Subscription > Explore All Plans flow

[trjExpensify]

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.1.68-7
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @trjExpensify
Slack conversation (hyperlinked to channel name): #convert

Action Performed:

1. Create a workspace
2. Go to Subscription > Explore All Plans
3. Click "Upgrade to Control" button

Expected Result:

This is an improvement.

Upgrade the workspace after clicking Upgrade to Control instead of showing an additional Upgrade modal, as it's effectively exactly the same information.

Actual Result:

After clicking "Upgrade to Control" we show another upgrade modal.

Workaround:

N/A

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[melvin-bot]

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

[FitseTLT]

Proposal

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

Remove the duplicate Upgrade modal in Subscription > Explore All Plans flow

What is the root cause of that problem?

In here we only navigate to upgrade page instead of upgrading

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Lines 62 to 64 in a69948d

	if (planType === CONST.POLICY.TYPE.CORPORATE) {
	Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));
	}

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

We can directly call upgradeToCorporate instead.

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Lines 62 to 64 in a69948d

	if (planType === CONST.POLICY.TYPE.CORPORATE) {
	Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));
	}

 if (planType === CONST.POLICY.TYPE.CORPORATE) {
            upgradeToCorporate(ownerPolicy);
        }

We can do the same for downgrade if needed downgradeToTeam

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Lines 57 to 59 in a69948d

	if (planType === CONST.POLICY.TYPE.TEAM) {
	Navigation.navigate(ROUTES.WORKSPACE_DOWNGRADE.getRoute(ownerPolicy, Navigation.getActiveRoute()));
	return;

In case of downgrade we show a modal if the policy has a company card

App/src/pages/workspace/downgrade/WorkspaceDowngradePage.tsx

Lines 45 to 48 in a69948d

	if (Object.keys(companyFeeds).length > 1) {
	setIsDowngradeWarningModalOpen(true);
	return;
	}

So we should implement that modal here in subscription or otherwise we can navigate the user to downgrade page and they can see the modal there.

Moreover we show not found page in the pages now if the user cannot canModifyPlan so we should consider this case here and display some message explaining it and disable upgrade or downgrade buttons.

Note for C+: regarding the policy to upgrade as I have explained above we will upgrade the ownerpolicy which we are clearly calculating to be the only one owned workspace which we already calculate here and upgrade or downgrade functions clearly require the policy id param so early returning when ownerPolicy doesn't exist is a straight forward case that's why I didn't mention 👍 BTW as an additional note both in the case of !ownerPolicy or !canModifyPlan we can consider hiding or disabling the buttons or showing some notes on the subscription plan that the user cannot modify plan or not showing subscription compare plan as a whole consulting with the design team.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N / A

What alternative solutions did you explore? (Optional)

[daledah]

Proposal

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

After clicking "Upgrade to Control" we show another upgrade modal.

What is the root cause of that problem?

In here we always go to workspace upgrade page

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Line 63 in 8ef40f6

Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));

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

We should only perform direct upgrade if there's only one workspace, otherwise we wouldn't now which workspace to upgrade

We can use same logics as WorkspaceUpgradePage with some modifications

    const [canPerformUpgrade, policy] = useMemo(() => {
        const firstPolicy = ownerPolicies.at(0);
        if (!firstPolicy || !firstPolicy.id || ownerPolicies.length > 1) {
            return [false, undefined];
        }
        return [canModifyPlan(firstPolicy.id), firstPolicy];
    }, [ownerPolicies]);

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Lines 62 to 64 in 8ef40f6

	if (planType === CONST.POLICY.TYPE.CORPORATE) {
	Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));
	}

        if (planType === CONST.POLICY.TYPE.CORPORATE) {
            if (canPerformUpgrade && !!policy?.id) {
                upgradeToCorporate(policy.id);
                return;
            }
            Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));
        }

We can make same changes to downgrading. The difference is we need to check if there's 1 collect WS instead of checking for 1 WS, and also implements similar to WorkspaceDowngradePage

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None based on issue description

What alternative solutions did you explore? (Optional)

NA

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[samranahm]

Proposal

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

Remove the duplicate Upgrade modal in Subscription > Explore All Plans flow

What is the root cause of that problem?

New feature

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

We want to upgrade the policy from SubscriptionPlanCard instead of navigating to upgrade RHP

so we should make ownerPolicy policy instead of policyID by removing id from ownerPolicies.at(0)?.id and use upgradeToCorporate like

const ownerPolicy = ownerPolicies.length === 1 ? ownerPolicies.at(0) : undefined;

if (!ownerPolicy) {
    return;
}


if (planType === CONST.POLICY.TYPE.CORPORATE) {
    upgradeToCorporate(ownerPolicy.id);
}

here

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Lines 55 to 64 in a95aef3

	const ownerPolicy = ownerPolicies.length === 1 ? ownerPolicies.at(0)?.id : undefined;
	if (planType === CONST.POLICY.TYPE.TEAM) {
	Navigation.navigate(ROUTES.WORKSPACE_DOWNGRADE.getRoute(ownerPolicy, Navigation.getActiveRoute()));
	return;
	}
	if (planType === CONST.POLICY.TYPE.CORPORATE) {
	Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(ownerPolicy, undefined, Navigation.getActiveRoute()));
	}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

We can use the same logic for downgrade the policy using downgradeToTeam

[eh2077]

Thank you for your proposals!

The root cause is clear. I think we should go with @daledah 's proposal because their solution is more thoughtful and was also submitted a bit earlier.

🎀👀🎀 C+ reviewed