[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [$250] IOU – Disabled distance rate is present in the rate list in confirmation page

[izarutskaya]

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: v1.4.74-1
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): [email protected]
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in and go to Collect workspace settings
3. Go to Distance rates
4. Click Add rate
5. Add a new rate
6. Disable existing rate
7. Go to workspace chat
8. Start submit distance flow
9. In confirmation page, click Rate

Expected Result:

Disabled distance rate is not present in the rate list in confirmation page

Actual Result:

Disabled distance rate is present in the rate list in confirmation page

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

Bug6482488_1715847912862.D_rate.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c1179d796babea5c
• Upwork Job ID: 1793173961329356800
• Last Price Increase: 2024-05-22
• Automatic offers:
• ikevin127 | Reviewer | 102499784
• cretadn22 | Contributor | 102499787

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

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

[izarutskaya]

We think this issue might be related to the #collect project.

[Krishna2323]

Proposal

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

IOU – Disabled distance rate is present in the rate list in confirmation page

What is the root cause of that problem?

We don't filter out the distances which are disabled.

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Lines 55 to 65 in fb14d5a

	const sections = Object.values(rates).map((rate) => {
	const rateForDisplay = DistanceRequestUtils.getRateForDisplay(rate.unit, rate.rate, rate.currency, translate, toLocaleDigit);
	return {
	text: rate.name ?? rateForDisplay,
	alternateText: rate.name ? rateForDisplay : '',
	keyForList: rate.customUnitRateID,
	value: rate.customUnitRateID,
	isSelected: lastSelectedRateID ? lastSelectedRateID === rate.customUnitRateID : Boolean(rate.name === CONST.CUSTOM_UNITS.DEFAULT_RATE),
	};
	});

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

Filter out the disabled rates and rates with pending action of delete.

What alternative solutions did you explore? (Optional)

Or we can add new parameters (includeDistanceRates,disatanceRates) to OptionsListUtils.getFilteredOptions and then create separate function to get the filtered rates, just like we do for categories, taxes and tags. The implementation will be mostly similar to the functions below. We can also create a separate component for distance rate selector, just like we do with CategoryPicker and TagPicker.

App/src/libs/OptionsListUtils.ts

Line 1390 in fb14d5a

function getTaxRatesSection(policy: OnyxEntry<Policy> | undefined, selectedOptions: Tax[], searchInputValue: string, transaction?: OnyxEntry<Transaction>): TaxSection[] {

App/src/libs/OptionsListUtils.ts

Line 1038 in fb14d5a

function getCategoryListSections(

App/src/libs/OptionsListUtils.ts

Line 1181 in fb14d5a

function getTagListSections(

[allgandalf]

Proposal

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

Disabled rates are present when choosing the rates for distance requests.

What is the root cause of that problem?

We get information about the rates from the prop passed to the component :

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Lines 38 to 44 in fb14d5a

	function IOURequestStepDistanceRate({
	policy,
	route: {
	params: {backTo, transactionID},
	},
	transaction,
	rates,

The value of rates is collected from Onyx:

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Lines 101 to 102 in fb14d5a

	rates: {
	key: ({report}) => `${ONYXKEYS.COLLECTION.POLICY}${report?.policyID ?? '0'}`,

But when we see the rates variable we do not have any field which can tell us whether the current distance rate has been enabled or not.

This is because we do not return the prop value of enabled in the selector using Onyx:

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Lines 102 to 103 in fb14d5a

	key: ({report}) => `${ONYXKEYS.COLLECTION.POLICY}${report?.policyID ?? '0'}`,
	selector: DistanceRequestUtils.getMileageRates,

This is because in DistanceRequestUtils.getMileageRates, we never return the value of enabled:

App/src/libs/DistanceRequestUtils.ts

Lines 202 to 208 in a03fecc

	mileageRates[rateID] = {
	rate: rate.rate,
	currency: rate.currency,
	unit: distanceUnit.attributes.unit,
	name: rate.name,
	customUnitRateID: rate.customUnitRateID,
	};

So even before thinking to filter the distance rates, we do not have enabled field present, so we display the rates using:

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Lines 58 to 63 in fb14d5a

	return {
	text: rate.name ?? rateForDisplay,
	alternateText: rate.name ? rateForDisplay : '',
	keyForList: rate.customUnitRateID,
	value: rate.customUnitRateID,
	isSelected: lastSelectedRateID ? lastSelectedRateID === rate.customUnitRateID : Boolean(rate.name === CONST.CUSTOM_UNITS.DEFAULT_RATE),

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

So to start with first we need to return the value of enabled in `getMileageRates``, we can do it by updating the return logic here:

Object.entries(distanceUnit.rates).forEach(([rateID, rate]) => {
        mileageRates[rateID] = {
            rate: rate.rate,
            currency: rate.currency,
            unit: distanceUnit.attributes.unit,
            name: rate.name,
            customUnitRateID: rate.customUnitRateID,
            enabled: rate.enabled,
        };
    });

We also need to update the type of MileageRate to include and extra conditional Prop enabled.

If there is extra change needed to deal with the case of offline mode, we can consider that too during the PR phase.

So now we only need to update the following mapping to filter the enabled rates below mapping:

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Line 55 in fb14d5a

const sections = Object.values(rates).map((rate) => {

const sections = Object.values(rates)
    .filter(rate => rate.enabled === true)
    .map((rate) => {

Result Video

Screen.Recording.2024-05-16.at.7.27.03.PM.mov

[cretadn22]

Proposal

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

We've encountered two issues:

1. The default rate shown on the confirmation page is incorrect. Even when disabled, it still appears as the default rate.
2. Disabled rates are visible in the list of distance rates.

What is the root cause of that problem?

Bug 1:

App/src/libs/DistanceRequestUtils.ts

Lines 255 to 264 in c19eea6

	function getCustomUnitRateID(reportID: string) {
	const report = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] ?? null;
	const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`] ?? null;
	const policy = PolicyUtils.getPolicy(report?.policyID ?? parentReport?.policyID ?? '');
	let customUnitRateID: string = CONST.CUSTOM_UNITS.FAKE_P2P_ID;
	if (ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isPolicyExpenseChat(parentReport)) {
	customUnitRateID = lastSelectedDistanceRates?.[policy?.id ?? ''] ?? getDefaultMileageRate(policy)?.customUnitRateID ?? '';
	}

We don't currently check if lastSelectedDistanceRates is disabled. Additionally, in the getDefaultMileageRate function, we're not excluding disabled rates either.

Bug 2:
We are using getMileageRates to get rate list in IOURequestStepDistanceRate. But in this function we don't filter out disabled rate

App/src/libs/DistanceRequestUtils.ts

Lines 189 to 211 in c19eea6

	function getMileageRates(policy: OnyxEntry<Policy>): Record<string, MileageRate> {
	const mileageRates: Record<string, MileageRate> = {};
	if (!policy || !policy?.customUnits) {
	return mileageRates;
	}
	const distanceUnit = Object.values(policy.customUnits).find((unit) => unit.name === CONST.CUSTOM_UNITS.NAME_DISTANCE);
	if (!distanceUnit?.rates) {
	return mileageRates;
	}
	Object.entries(distanceUnit.rates).forEach(([rateID, rate]) => {
	mileageRates[rateID] = {
	rate: rate.rate,
	currency: rate.currency,
	unit: distanceUnit.attributes.unit,
	name: rate.name,
	customUnitRateID: rate.customUnitRateID,
	};
	});
	return mileageRates;

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

App/src/libs/DistanceRequestUtils.ts

Line 263 in c19eea6

customUnitRateID = lastSelectedDistanceRates?.[policy?.id ?? ''] ?? getDefaultMileageRate(policy)?.customUnitRateID ?? '';

• Introduce a condition to check if lastSelectedDistanceRates is disabled. If it is, we will use the getDefaultMileageRate function to retrieve the default rate.

• Modify the getMileageRates function to include a parameter such as includeDisableRate. If this parameter is set to false, we will filter out disabled rates.

• Update the getDefaultMileageRate and IOURequestStepDistanceRate to utilize getMileageRates with includeDisableRate set to false.

This is draft implementation: #42330 (UPDATED)

What alternative solutions did you explore? (Optional)

If we don't want to add new param to getMileageRates function we can manually filter out the disable rate in

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Line 103 in c19eea6

selector: DistanceRequestUtils.getMileageRates,

App/src/libs/DistanceRequestUtils.ts

Line 263 in c19eea6

customUnitRateID = lastSelectedDistanceRates?.[policy?.id ?? ''] ?? getDefaultMileageRate(policy)?.customUnitRateID ?? '';

and keep this bullet point within the primary solution.

• Introduce a condition to check if lastSelectedDistanceRates is disabled. If it is, we will use the getDefaultMileageRate function to retrieve the default rate.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01c1179d796babea5c

[JmillsExpensify]

Opening this up to the community.

[melvin-bot]

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

[Krishna2323]

@ikevin127, test branch for my alternative solution. This will make the distance selector behave exactly like tag/category/tax pickers. Currently we don't have search functionality also.

[ikevin127]

@Krishna2323 Thank you for your proposal. Your proposal's RCA is incomplete as only filtering out the disabled distance rates from the Rate option selector is not enough to fix this issue. See cretadn22's proposal RCA for more details.

Your main solution is not detailed enough for me to assess whether or not it would fix the issue. Even if it would be, since the RCA is not complete, it would most likely not tackle the issue fully.

Regarding your alternative solution, I think it adds too much overhead and new code when not necessary - besides this, I'm reserved when it comes to adding 2 additional arguments to a function that already has 23 arguments. I checked out your test branch and the same thing mentioned above applies:

only filtering out the disabled distance rates from the Rate option selector is not enough to fix this issue

Besides not fixing the issue completely, due to the changes from your test branch -> now there's no more difference in the UI when it comes to canUseAllBetas being true or false -> the Rate field is always visible as if canUseAllBetas is always true.

canUseAllBetas -> false on current main	canUseAllBetas -> false / true (your test branch)

[ikevin127]

@GandalfGwaihir Thank you for your proposal. Your proposal's RCA is incomplete as only filtering out the disabled distance rates from the Rate option selector is not enough to fix this issue. See cretadn22's proposal RCA for more details.

Your proposed solution only filters out the disabled distance rates from the Rates selector but if you follow the OP video carefully, once the new distance rate was added, the existing (default) one was disabled -> when reaching the confirmation page even though the existing (default) distance rate is disabled -> it still shows up as the default selected rate in the Rate option for both canUseAllBetas true and false UI variations, even though the rate is disabled.

[ikevin127]

@cretadn22 Thank you for your proposal. Your proposal's RCA is correct. Your solution is problematic since you don't clearly mention which part of the issue the suggested change is targeting. Additionally, your test branch does not help me in assessing whether your solution is working because of the following reasons:

1. It only implements 2 of the suggested bullet-point changes from your solution, the first bullet-point does not seem to be accounted for.
2. It uses getMileageRates before the function is defined.
3. I'm reserved when it comes to implementing the logic which includes the includeDisableRate argument as I think there's better and simpler ways of tackling this, avoiding the addition of unnecessary arguments.

[ikevin127]

Notes for contributors

Some pointers regarding issue complexity

This issue has 2 sides to it, see cretadn22's proposal RCA for more details. To get a better sense of the root cause I'd advise following these steps:

Tip

1. Log in and go to Collect workspace settings.
2. Go to Distance rates.
3. Click [+ Add rate].
4. Add a new rate.
5. Disable previously existing rate (0.67) such that only the newly added rate is Enabled.

Now before following the rest of the steps from OP, know that there are 2 different ways the UI can look when arriving on the Distance request confirmation page, and this differs based on whether your account canUseAllBetas.

canUseAllBetas -> false	canUseAllBetas -> true (OP)

Note: This can be enabled / disabled from src/libs/Permissions.ts by hardcode returning true / false for the canUseAllBetas function.

Some RCA & Solution pointers (from a reviewer's POV)

✅ Have a clear RCA that accounts for the entirety of the issue.
✅ Have a clear and technically detailed implementation of the solution, instead of a vague sentence.
✅ We need a solution which tackless the root cause for both canUseAllBetas UI scenarios, including consideration for offline pattern (if any).
✅ We need a clear and detailed technical implementation of the solution which I'm able to test OR a test branch which aligns with your proposal's solution. The test branch should reflect the final implementation as close as possible.

❌ Avoid adding extra parameters to existing functions which already have too many parameters.
❌ Avoid creating a test branch which does not entirely match everything mentioned in the proposed solution changes. Additionally, don't use variable / function names like abc as the test branch should reflect the final implementation as close as possible.

Important

The first contributor to update / post a new proposal considering all of the above will be selected on a first come, first served basis.

cc @Krishna2323 @GandalfGwaihir @cretadn22

[cretadn22]

@ikevin127 I updated proposal (I updated the detail implementation to address your comment)

I'm reserved when it comes to implementing the logic which includes the includeDisableRate argument as I think there's better and simpler ways of tackling this, avoiding the addition of unnecessary arguments.

In certain instances, you may require the disabled rate, while in others, filtering out the disabled rate is necessary. Therefore, I propose the addition of the 'includeDisableRate' parameter. This adjustment enhances the flexibility of the getMileageRates function and ensures adherence to the DRY (Don't Repeat Yourself) principle

[nkdengineer]

Proposal

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

Disabled distance rate is present in the rate list in confirmation page

What is the root cause of that problem?

1. We don't clear lastSelectedDistanceRates of the policy when the rate is disable

2. We don't filter out the disabled rate here so the disabled rates still present in distance rate step page

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Line 55 in aa9bbcf

const sections = Object.values(rates).map((rate) => {

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

1. We should clear lastSelectedDistanceRates of a policy when the rate is disable. To do that we can handle the same way we handle report change here. It's something like this in Policy actions

const allPolicies: OnyxCollection<Policy> = {};
Onyx.connect({
    key: ONYXKEYS.COLLECTION.POLICY,
    callback: (val, key) => {
        ...
        handlePolicyChange(val);

        allPolicies[key] = val;
    },
});
let lastSelectedDistanceRates: OnyxEntry<LastSelectedDistanceRates> = {};
Onyx.connect({
    key: ONYXKEYS.NVP_LAST_SELECTED_DISTANCE_RATES,
    callback: (value) => {
        lastSelectedDistanceRates = value;
    },
});

function handlePolicyChange(policy: OnyxEntry<Policy>) {
    if (!policy || !lastSelectedDistanceRates?.[policy?.id ?? '']) {
        return;
    }

    const rateID = lastSelectedDistanceRates?.[policy?.id ?? ''];
    const distanceUnit = Object.values(policy?.customUnits ?? {}).find((unit) => unit.name === CONST.CUSTOM_UNITS.NAME_DISTANCE);
    const distanceRate = distanceUnit?.rates?.[rateID];

    if (!distanceRate?.enabled) {
        Onyx.merge(ONYXKEYS.NVP_LAST_SELECTED_DISTANCE_RATES, {[policy.id] : null});
    }
}

2. In getDefaultMileageRate, we should return an extra field enabled: rate.enabled to know a rate is disabled or not

App/src/libs/DistanceRequestUtils.ts

Line 51 in aa9bbcf

function getDefaultMileageRate(policy: OnyxEntry<Policy> | EmptyObject): MileageRate | null {

3. To make distance rate step has the same behavior with other steps like tag, category, we will filter out that disabled rate that isn't the selected rate and return an extra field isDisabled: !rate.enable. So if the selected rate is disabled, it can be displayed with grey out

const sections = Object.values(rates).filter((rate) => rate.enabled || rate.customUnitRateID === lastSelectedRateID).map((rate) => {
    const rateForDisplay = DistanceRequestUtils.getRateForDisplay(rate.unit, rate.rate, rate.currency, translate, toLocaleDigit);

    return {
        ...
        isDisabled: !rate.enabled,
    };
});

App/src/pages/iou/request/step/IOURequestStepDistanceRate.tsx

Line 55 in aa9bbcf

const sections = Object.values(rates).map((rate) => {

What alternative solutions did you explore? (Optional)

NA

[ikevin127]

♻️ Reviewing proposals once again.

[ikevin127]

@nkdengineer Thank you for your proposal. Your proposal's RCA is correct and complete since it was already pointed out previously. As far as your solution goes, though it would fix the issue, due to the different route you approached when it comes to disabling the Rate list options -> this does not match with the expected result which states:

Disabled distance rate is not present in the rate list in confirmation page

If the assigned CME decides that we want to involve design and adjust the expected result to match your proposed solution, then I would be willing to reconsider assignment.

cc @neil-marcellini

[ikevin127]

@cretadn22's updated proposal looks good to me! They were first to identify the root cause correctly and completely and first to update their proposal after initial review. Their updated main solution / test branch fixes the issue accordingly as per issue's expected result by:

1. Defaulting distance rate to the first enabled when the Rate field is not shown (users with betas disabled).
2. (1.) + Not displaying the disabled distance rates in the Rate field list (users with betas enabled).

Video / Screenshot of Fix

canUseAllBetas -> true	canUseAllBetas -> false
canUseAllBetas.mov

🎀👀🎀 C+ reviewed

[cretadn22]

@ikevin127 The PR here #42330. It is ready for your review

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[cretadn22]

@ikevin127 Our PR isn't reverted, regressions also be fixed by another PR. No action is required on our part in this situation.

[ikevin127]

@cretadn22 Sorry, my bad - I just noticed the revert PR being closed and the issue being fixed somewhere else.
@neil-marcellini So the regression was indeed caused by our PR, or it was another PR / unrelated based on #43208 (comment) ?

Note: The initial PR was merged 7-days ago but never deployed to staging / production.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.81-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Disabled distance rate is present in the rate list in confirmation p #42330

If no regressions arise, payment will be issued on 2024-06-18. 🎊

For reference, here are some details about the assignees on this issue:

• @ikevin127 requires payment automatic offer (Reviewer)
• @cretadn22 requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@ikevin127] The PR that introduced the bug has been identified. Link to the PR:
• [@ikevin127] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@ikevin127] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@ikevin127] Determine if we should create a regression test for this bug.
• [@ikevin127] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@JmillsExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.82-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Disabled distance rate is present in the rate list in confirmation p #42330

If no regressions arise, payment will be issued on 2024-06-20. 🎊

For reference, here are some details about the assignees on this issue:

• @ikevin127 requires payment automatic offer (Reviewer)
• @cretadn22 requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@ikevin127] The PR that introduced the bug has been identified. Link to the PR:
• [@ikevin127] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@ikevin127] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@ikevin127] Determine if we should create a regression test for this bug.
• [@ikevin127] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@JmillsExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[ikevin127]

• [@ikevin127] The PR that introduced the bug has been identified. Link to the PR: #38543.
• [@ikevin127] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: #38543 (comment).
• [@ikevin127] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• [@ikevin127] Determine if we should create a regression test for this bug.
• [@ikevin127] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Proposal

Test 1

Precondition: User does NOT have betas enabled, hence no Rate field will be displayed in Distance confirmation page.

1. Log in and go to a new Collect workspace settings page.
2. Enable Distance rates and go to Distance rates page.
3. Click [+ Add rate].
4. Add a new rate and make sure it's Enabled.
5. Disable previously existing distance rate (the default $0.670 / mile rate).
6. Go to the workspace chat.
7. Click composer [+] and proceed to Submit expense > Distance request.
8. On Distance confirmation page, verify that the enabled rate is set as default in the Distance field (see below).

Test 2

Precondition: User does have betas enabled, hence the Rate field will be displayed in Distance confirmation page.

1. Log in and go to a new Collect workspace settings page.
2. Enable Distance rates and go to Distance rates page.
3. Click [+ Add rate].
4. Add a new rate and make sure it's Enabled.
5. Disable previously existing distance rate (the default $0.670 / mile rate).
6. Go to the workspace chat.
7. Click composer [+] and proceed to Submit expense > Distance request.
8. On Distance confirmation page, verify that the enabled rate is set as default in the Rate field (see [1.]).
9. On Distance confirmation page, click on the Rate field and verify that the disabled rate is not displayed (see [2.]).

1	2

Do we agree 👍 or 👎.

[ikevin127]

⚠️ Not sure why the automation added the second HOLD date her, since the PR was deployed 4 days ago according to #42330 (comment) -> therefore the [HOLD for payment 2024-06-18] is the correct payment date.

Summary:

• PR was merged 2 weeks ago according to automation #42330 (comment) but wasn't deployed to staging / production
• PR was deployed to production 4 days ago -> compensation due for contributor / reviewer on 2024-06-18

Note: Some regressions were associated with this PR, which if confirmed -> the compensation will be reduced. I asked @neil-marcellini to confirm this above in #42284 (comment) so that everything is clear and ready for payment when due.

cc @JmillsExpensify

[neil-marcellini]

Yes there was a regression caused by #42330

[dylanexpensify]

Payment issued to @ikevin127 and @cretadn22 factoring in regression 👍

[dylanexpensify]

done