[$250] Workspace owner is able to attempt to downgrade subscription to Collect when they’ve got a Control subscription

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
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: @garrettmknight
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Pre-req: Have a Control subscription, past the free trial and grace period.

1. Go to Account > Subscriptions
2. Click ‘Explore all plans’
3. Click ‘Downgrade to Collect’

Expected Result:

The user is notified that they cannot downgrade since they’re on an active Control subscription

Actual Result:

Since the user is on an active subscription and canDowngrade = false, the user is presented with the option to ‘Downgrade workspace’ and selecting it shows success on the FE, but fails on the BE.
To solve, we can reuse the ‘Subscription size’ RHP, just updating the header to read ‘Plan type’.

Workaround:

Unknown

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

Add any screenshot/video evidence

Screen.Recording.2025-07-02.at.1.15.11.PM.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021944736832361366598
• Upwork Job ID: 1944736832361366598
• Last Price Increase: 2025-07-14
• Automatic offers:
• allgandalf | Reviewer | 108037453
• twilight2294 | Contributor | 108037458

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @flaviadefaria

[melvin-bot]

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

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[twilight2294]

Proposal

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

Workspace owner is able to attempt to downgrade subscription to Collect when they’ve got a Control subscription

What is the root cause of that problem?

We don't have any condition to check for the case of active control workspace and the blocking screen navigation.

So we allow the action on the FE and block it on the backend.

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

Lines 94 to 97 in 32f0755

	text={translate('subscription.yourPlan.downgrade')}
	style={style}
	onPress={() => handlePlanPress(CONST.POLICY.TYPE.TEAM)}
	/>

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

We need to implement similar changes as we did when we tried to switch to pay per use and navigate to the blocking screen.

App/src/pages/settings/Subscription/SubscriptionSettings/index.tsx

Lines 84 to 87 in 32f0755

	if (privateSubscription?.type === CONST.SUBSCRIPTION.TYPE.ANNUAL && option === CONST.SUBSCRIPTION.TYPE.PAY_PER_USE && !account?.canDowngrade) {
	Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_SIZE.getRoute(0));
	return;
	}

Condition like above

We would need to update the handlePlanPress:

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

Lines 56 to 58 in 32f0755

	const handlePlanPress = (planType: PersonalPolicyTypeExcludedProps) => {
	closeComparisonModal?.();

    const handlePlanPress = (planType: PersonalPolicyTypeExcludedProps) => {
        closeComparisonModal?.();

        // If user has no policies, return.
        if (!ownerPolicies.length) {
            return;
        }

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

        if (planType === CONST.POLICY.TYPE.TEAM && privateSubscription?.type === CONST.SUBSCRIPTION.TYPE.ANNUAL && !account?.canDowngrade) {
            Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_SIZE.getRoute(0));
            return;
        }

We can create this page to of the blocking modal to be more generic such that we can share them between both the pages, we can update the route name too !

just updating the header to read ‘Plan type’.

We would also update the header to read plan type, so basically we would create a new generic RHP / create a dedicated RHP either ways work
The navigation on back button press can be decided during PR.

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

N/A, but if we need to can write a UI test to render the screen and verify that we navigate to the blocking screen when we have control subscription

What alternative solutions did you explore? (Optional)

N/A

[allgandalf]

I can reproduce this issue with the steps in the OP:

Screen.Recording.2025-07-02.at.6.56.23.PM.mov

@flaviadefaria Please assign me as C+ here as per this slack post:

The first C+ to post on the GH issue with reliable reproduction steps and video or screenshots confirming reproduction will be assigned as C+.
Please add a :white_tick: to the message if you have posted reliable steps on the issue.

[allgandalf]

@flaviadefaria can you please assign this issue to me as C+ and then make the issue external?

[melvin-bot]

@flaviadefaria Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

@flaviadefaria 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

@flaviadefaria 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!