[HOLD #44582] Workspace - Distance rate enabled offline when creating the workspace online not grayed

[izarutskaya]

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.0-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): nahummelaku9+A3@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Log in to staging.new.expensify.com
2. Create a new workspace
3. Navigate to more features
4. Go offline
5. Enable Distance rates
6. Navigate to Distance rates

Expected Result:

List of rates should be grayed out.

Actual Result:

List of rates is not grayed out.

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

Bug6519172_1718870652762.Distance_rate_is_not_grayed_out_when_creating_workspace_online_and_enabling_distance_rate_in_offline.mp4

View all open jobs on GitHub

[melvin-bot]

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

[bernhardoj]

Proposal

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

The distance rates aren't grayed out when enabling the distance rate while offline.

What is the root cause of that problem?

When we create a new workspace, the distance rates are already added to the workspace. When the workspace creating is still pending, we also add it as the distance rate pending action.

App/src/pages/workspace/distanceRates/PolicyDistanceRatesPage.tsx

Line 118 in 7512346

(policy?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD ? policy?.pendingAction : undefined),

After the request is complete, there is no pending action anymore. When we enable the distance rate, the list won't be grayed out because the pending action is already done.

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

If we still want to grayed it out when enabling it while offline, then we can add a
policy?.pendingFields?.areDistanceRatesEnabled,
condition so it's grayed out when the distance rate is enabled while offline.

App/src/pages/workspace/distanceRates/PolicyDistanceRatesPage.tsx

Lines 113 to 118 in 7512346

	pendingAction:
	value.pendingAction ??
	value.pendingFields?.rate ??
	value.pendingFields?.enabled ??
	value.pendingFields?.currency ??
	(policy?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD ? policy?.pendingAction : undefined),

[mallenexpensify]

Checking on in  #wave-collect

Noticing a lot of Offline Distance issues lately. Are these being addresses holistically anywhere? (asking cuz I'm assigned to one and considering next steps)

[OfstadC]

This seems pretty similar

[mallenexpensify]

Yeah, please hold here, trying to figure out a holistic plan, since there are a lot of these

[OfstadC]

Sounds good Matt!

[mallenexpensify]

@paultsimura , please comment so I can assign to you

[paultsimura]

👋🏼

[melvin-bot]

@mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[paultsimura]

Could we please get this issue cleared out a little?
Specifically, why should the rate be greyed out the second time we enable the distance rates offline?

The first time it's greyed out because the rates are enabled offline for the first time, and the default rate must be created, so it's in the pending status until coming back online.

The second time we disable-enable the rates, the default rate is not getting either re-created or modified – meaning it has no pending action, so why should it be greyed out?

cc: @mallenexpensify

[mallenexpensify]

@paultsimura I think the vid is supposed to show that there's discrepancy when creating new workspaces and then going offline and adjusting the mileage rate. I'm assuming that when a new workspace is created, we're not carrying over any distance rate info from other workspaces, is that correct?

[paultsimura]

@mallenexpensify

there's discrepancy when creating new workspaces and then going offline and adjusting the mileage rate

There is one, and it's visible in the recording. But in my understanding, it's a normal expected behavior. That's why I would like to understand better why the issue reporter expects the rates to be greyed out in the second scenario.

we're not carrying over any distance rate info from other workspaces

Yes, the workspaces are not connected in that matter. When a new workspace is created, the default rate is created when we enable the distance rates.

[mallenexpensify]

Stepping back, to make sure I'm understanding things. From the vid it appears the user creates a new workspace, goes offline, does distance and the mileage rate is greyed out. They then do the same (or very similar) steps again and that time, the mileage rate isn't greyed out. Is that correct? And, if so, do you know what that's happening?

[paultsimura]

From the vid it appears the user creates a new workspace, goes offline, does distance and the mileage rate is greyed out.

One step is missing here: goes offline – enables the distance rates for the first time – checks the mileage rates.

When a new workspace is created, it has no distance rate. When the user enables the distance rates for the first time, the default rate is created.
Since this is done offline, the rates get enabled for the first time, and the default rate is in the pending "create" state – that's why it's greyed out. IMO that's expected.

They then do the same (or very similar) steps again and that time, the mileage rate isn't greyed out. Is that correct?

Yes, and IMO this is expected as well, because the second time we enable-disable the rates, the default rate has no pending action, so it shouldn't be greyed out.

WDYT @mallenexpensify?

[mallenexpensify]

Thx for the details @paultsimura , sounds like we should close this then, it's working as expected. Right?

[paultsimura]

Yes, IMO this is an expected behavior.