[$250] Distance rates - Distance rate is not grayed out when workspace is created offline

[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!

---

#issue found when validating #43071
Version Number: 1.4.82-0
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: Applause internal team
Slack conversation:

Action Performed:

1. Go to staging.new.expensify.com
2. Go offline.
3. Create a new workspace.
4. Go to Categories.
5. Note that all categories are grayed out.
6. Go to More features.
7. Enable Distance rates.
8. Go to Distance rates.

Expected Result:

The distance rate in the list will be grayed out.

Actual Result:

The distance rate in the list is not grayed out when workspace is created offline.

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

Bug6510123_1718152969559.20240612_083929.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017bdb049912130299
• Upwork Job ID: 1800954285340721751
• Last Price Increase: 2024-06-12

Issue Owner

Current Issue Owner: @ahmedGaber93

[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.

[m-natarajan]

@isabelastisser FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[m-natarajan]

We think that this bug might be related to #wave-collect - Release 1

[etCoderDysto]

Proposal

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

The distance rate in the list is not grayed out when workspace is created offline.

What is the root cause of that problem?

distanceRatesList[0].pendingAction is undefined in PolicyDistanceRatesPage because there is no pendingAction property on policy.customUnits[customUnitID].rates[customUnitRateID] object. This is because we are not adding pendingAction property in customUnits.rates[customUnitRateID] object when we create an optimistic customUnits for a newly created workspace.

App/src/libs/actions/Policy/Policy.ts

Lines 1406 to 1411 in 95c8202

	[customUnitRateID]: {
	customUnitRateID,
	name: CONST.CUSTOM_UNITS.DEFAULT_RATE,
	rate: CONST.CUSTOM_UNITS.MILEAGE_IRS_RATE * CONST.POLICY.CUSTOM_UNIT_RATE_BASE_OFFSET,
	enabled: true,
	currency,

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

Add pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD; in customUnits.rates[customUnitRateID]

App/src/libs/actions/Policy/Policy.ts

Lines 1406 to 1411 in 95c8202

	[customUnitRateID]: {
	customUnitRateID,
	name: CONST.CUSTOM_UNITS.DEFAULT_RATE,
	rate: CONST.CUSTOM_UNITS.MILEAGE_IRS_RATE * CONST.POLICY.CUSTOM_UNIT_RATE_BASE_OFFSET,
	enabled: true,
	currency,

What alternative solutions did you explore? (Optional)

N/A

Result:

Screen.Recording.2024-06-12.at.4.00.42.in.the.afternoon.mp4

[Krishna2323]

Proposal

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

Distance rates - Distance rate is not grayed out when workspace is created offline

What is the root cause of that problem?

We don't have pending action field for default rate.

App/src/libs/actions/Policy/Policy.ts

Lines 1406 to 1412 in 79e619a

	[customUnitRateID]: {
	customUnitRateID,
	name: CONST.CUSTOM_UNITS.DEFAULT_RATE,
	rate: CONST.CUSTOM_UNITS.MILEAGE_IRS_RATE * CONST.POLICY.CUSTOM_UNIT_RATE_BASE_OFFSET,
	enabled: true,
	currency,
	},

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

Instead of adding the pending action property in the object we can simply check for policy?.pendingAction === 'add' for rate with CONST.CUSTOM_UNITS.DEFAULT_RATE name.

    const distanceRatesList = useMemo<RateForList[]>(
        () =>
            Object.values(customUnitRates).map((value) => {
                const isPendingDefaultRate = value.name === CONST.CUSTOM_UNITS.DEFAULT_RATE && policy?.pendingAction === 'add' ? 'update' : undefined;
                return {
                    value: value.customUnitRateID ?? '',
                    text: `${CurrencyUtils.convertAmountToDisplayString(value.rate, value.currency ?? CONST.CURRENCY.USD)} / ${translate(
                        `common.${customUnit?.attributes?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES}`,
                    )}`,
                    keyForList: value.customUnitRateID ?? '',
                    isSelected: selectedDistanceRates.find((rate) => rate.customUnitRateID === value.customUnitRateID) !== undefined,
                    isDisabled: value.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
                    pendingAction: value.pendingAction ?? value.pendingFields?.rate ?? value.pendingFields?.enabled ?? value.pendingFields?.currency ?? isPendingDefaultRate,
                    errors: value.errors ?? undefined,
                    rightElement: <ListItemRightCaretWithLabel labelText={value.enabled ? translate('workspace.common.enabled') : translate('workspace.common.disabled')} />,
                };
            }),
        [customUnit?.attributes?.unit, customUnitRates, selectedDistanceRates, translate, policy?.pendingAction],
    );

Or we can just add || policy?.pendingAction to pendingAction field.

Note: we will use the pending action name from CONST file.

What alternative solutions did you explore? (Optional)

We can add the pendingAction: 'add', to the default rate object when creating it using buildOptimisticCustomUnits and we can also return a object for success and failure data, which we will use when policy is created or creation is failed.

    const customUnitsSuccess: Record<string, CustomUnit> = {
        [customUnitID]: {
            rates: {
                [customUnitRateID]: {
                    pendingAction: null,
                },
            },
        },
    };

    return {
        customUnits,
        customUnitID,
        customUnitRateID,
        outputCurrency: currency,
        customUnitsSuccess,
    };

Then use the customUnitsSuccess object in the value here and here.

Note: We also need to update the types and we can use the object in the success and failure data directly without returning it from buildOptimisticCustomUnits or we can create buildSuccessCustomUnits for failure and success data.

[Krishna2323]

Proposal Updated

• Added alternative

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~017bdb049912130299

[melvin-bot]

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

[Krishna2323]

Proposal Updated

• Minor update

[isabelastisser]

Bump @ahmedGaber93 to review the proposals above. Thanks!

[ahmedGaber93]

Reviewing

[ahmedGaber93]

@etCoderDysto Thanks for the proposal, adding pendingAction: 'add' in optimistic data will fix the issue, but you missed to mention remove it in success and failure data, and this will cause a regression when user back again to offline, the item color will back gray again.

regression video

20240614235630442.mp4

I think we can move forward with @Krishna2323's alternative solutions which cover remove pendingAction: 'add' in success and failure data.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @tylerkaraszewski, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[etCoderDysto]

You are right, @ahmedGaber93. But I am not sure how adding 'pendingAction' in success data can be possible since we have to add it to customUnits:{ customUnitID: {rates: customUnitRateID: { pendingAction: null}}}. How can we access customUnits and customUnitRateID values for the current policy in success data? And this logic might not cover a scenario where the user creates workspace in online mode, and then toggles distance rate in offline mode. I don't think success data will clear the pending action in this scenario.

[ahmedGaber93]

How can we access customUnits and customUnitRateID values for the current policy in success data?

We don't handle it manual, we just need to pass it to API lib, and it will merge them. successData here not mean the API response data, but it means merge this when api success, and it mostly used to revert some optimisticData like loading state

API.write(WRITE_COMMANDS.CREATE_WORKSPACE, params, {optimisticData, successData, failureData});

[etCoderDysto]

Got it! Thanks for the explanation 🙏

[melvin-bot]

@tylerkaraszewski, @isabelastisser, @ahmedGaber93 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ahmedGaber93]

Ready to assignment

[etCoderDysto]

This issue seems to be fixed here

[tylerkaraszewski]

Can we check and see if this is already fixed and close this if so?

[ahmedGaber93]

checking

[ahmedGaber93]

I can't reproduce the issue in the latest main

20240620200426707.mp4

[tylerkaraszewski]

@isabelastisser - do we need to do anything special here for the C+ who's looked at this so far or can we just close it?

[isabelastisser]

I believe we can close this. @ahmedGaber93 please let us know if you disagree. Thanks!