Expense - Employee is able to submit expenses to a workspace with a expired subscription

[isagoico]

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: v9.1.13-4
Reproducible in staging?: Yes
Reproducible in production?: Yes

Email or phone of affected tester (no customers): [email protected]
Logs: https://stackoverflow.com/c/expensify/questions/4856

Issue reported by: Applause - Internal Team
Slack conversation (hyperlinked to channel name): #qa
App Component: Money Requests

Action Performed:

Preconditions: Account is a employee of a workspace with an expired subscription

1. Log in as the employee of a workspace with an expired subscription
2. Navigate to the workspace chat
3. Submit a expense

Expected Result:

The employee should be unable to submit a expense in a workspace with an expired subscription.

Actual Result:

Employee is able to submit a expense in a workspace with an expired subscription.

For reference, here's the account and workspace ID used to reproduce this issue:

• Expired Workspace ID: 72151F6AD9D527CB
• Employee email: [email protected]

Note: the admin of the workspace is unable to submit expenses and is blocked with the expected blocking screen. This is ONLY affecting employees of the workspace.

Workaround:

N/A

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

View all open jobs on GitHub

[melvin-bot]

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

This might be expected. We allow a user with expired subscription submit to workspaces they don't own. But if we want to change the behavior we can remove isPolicyOwner in the conditions in shouldRestrictUserBillableActions here

App/src/libs/SubscriptionUtils.ts

Lines 505 to 538 in b09e2d1

	function shouldRestrictUserBillableActions(policyID: string): boolean {
	const currentDate = new Date();
	const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${policyID}`];
	// This logic will be executed if the user is a workspace's non-owner (normal user or admin).
	// We should restrict the workspace's non-owner actions if it's member of a workspace where the owner is
	// past due and is past its grace period end.
	for (const userBillingGraceEndPeriodEntry of Object.entries(userBillingGraceEndPeriodCollection ?? {})) {
	const [entryKey, userBillingGracePeriodEnd] = userBillingGraceEndPeriodEntry;
	if (userBillingGracePeriodEnd && isAfter(currentDate, fromUnixTime(userBillingGracePeriodEnd.value))) {
	// Extracts the owner account ID from the collection member key.
	const ownerAccountID = Number(entryKey.slice(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_USER_BILLING_GRACE_PERIOD_END.length));
	if (isPolicyOwner(policy, ownerAccountID)) {
	return true;
	}
	}
	}
	// If it reached here it means that the user is actually the workspace's owner.
	// We should restrict the workspace's owner actions if it's past its grace period end date and it's owing some amount.
	if (
	isPolicyOwner(policy, currentUserAccountID) &&
	ownerBillingGraceEndPeriod &&
	amountOwed !== undefined &&
	amountOwed > 0 &&
	isAfter(currentDate, fromUnixTime(ownerBillingGraceEndPeriod))
	) {
	return true;
	}
	return false;