[$250] Distance rate can be deleted from 3-dot menu when there is only one rate

[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: 1.4.70-0 Reproducible in staging?: Yes Reproducible in production?: No 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:

Precondition:

• There is only one default distance rate in the workspace.

1. Go to staging.new.expensify.com
2. Go to Account settings > Workspaces > any workspace.
3. Go to Distance rates.
4. Go offline.
5. Add a distance rate,
6. Delete the default workspace rate (not the newly-added rate).
7. Click on the checkbox of the newly added distance rate.
8. Select Delete option from the dropdown.
9. Note that the distance rate cannot be deleted because there must be at least one distance rate.
10. Click on the distance rate row.
11. Delete it from the three-dot menu.

Expected Result:

App will show the same pop-up in Step 9 that the distance rate cannot be deleted as there is only one distance rate.

Actual Result:

Distance rate can be deleted from 3-dot menu when there is only one distance rate.

Workaround:

Unknown

Platforms:

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

• [x] Android: Native
• [X] Android: mWeb Chrome
• [X] iOS: Native
• [X] iOS: mWeb Safari
• [X] MacOS: Chrome / Safari
• [X] MacOS: Desktop

Screenshots/Videos

https://github.com/Expensify/App/assets/38435837/97c23378-1afb-4eeb-8441-f0f0a33dbb8a

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0144c3fd2f5960b3c2
• Upwork Job ID: 1786441064248098816
• Last Price Increase: 2024-05-03
• Automatic offers:
• cretadn22 | Contributor | 0

Issue Owner

Current Issue Owner: @sobitneupane

[melvin-bot[bot]]

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

@slafortune 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

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~0144c3fd2f5960b3c2

[melvin-bot[bot]]

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

[Krishna2323]

Proposal

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

Distance rate can be deleted from 3-dot menu when there is only one rate

What is the root cause of that problem?

The condition canDeleteRate isn't correct. https://github.com/Expensify/App/blob/75b3863ac50e59f6032cea9e9d73e276add18677/src/pages/workspace/distanceRates/PolicyDistanceRateDetailsPage.tsx#L50-L51

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

Remove || !rate.enabled check because user should not be able to delete the receipt until there is one more rate with enabled state. Also, I think we should canDeleteRate and canDisableRate filter out the rates that has pending action value delete. We might also want to filter out the rates with pending action value add. If we are going to filter out rates with pending action value add then we would also need to update that in PolicyDistanceRatesPage.

Optionally, we can filter out as stated above without removing || !rate.enabled check

Also check for other policy pages that has similar functionality

What alternative solutions did you explore? (Optional)

Only change the canDisableRate condition to exclude the rates with pending action delete and also add if needed.

[Krishna2323]

Proposal Upadated

• Updated main solution

[Krishna2323]

Proposal Upadated

• Added alternative

[cretadn22]

Proposal

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

Users can delete all distance rate

What is the root cause of that problem?

https://github.com/Expensify/App/blob/387ab0edd9d2c01c2a0be72950490c94b1b7d9d9/src/pages/workspace/distanceRates/PolicyDistanceRateDetailsPage.tsx#L50-L51

We don't filter out the distance rate with a pendingAction of DELETE

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

See the logic in PolicyDistanceRatesPage, It works well https://github.com/Expensify/App/blob/387ab0edd9d2c01c2a0be72950490c94b1b7d9d9/src/pages/workspace/distanceRates/PolicyDistanceRatesPage.tsx#L66-L68

To ensure consistency, we should implement the same solution for PolicyDistanceRatesPage: (but using the current rate instead of selectedDistanceRates)

1. Introduce a new variable

   
   const allSelectableRates = Object.values(customUnit.rates).filter((rate) => rate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
   const canDisableOrDeleteSelectedRates = allSelectableRates.filter((rate: Rate) => rateID !== rate.customUnitRateID).some((rate) => rate.enabled)

2. Utilize canDisableOrDeleteSelectedRates instead of canDeleteRate and canDisableRate, similar to what was done in the PolicyDistanceRatesPage

Moreover, creating a utility function could help maintain a DRY (Don't Repeat Yourself) codebase.
### What alternative solutions did you explore? (Optional)

**Reminder:** Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

<!---
ATTN: Contributor+

You are the first line of defense in making sure every proposal has a clear and easily understood problem with a "root cause". Do not approve any proposals that lack a satisfying explanation to the first two prompts. It is CRITICALLY important that we understand the root cause at a minimum even if the solution doesn't directly address it. When we avoid this step, we can end up solving the wrong problems entirely or just writing hacks and workarounds.

Instructions for how to review a proposal:

1. Address each contributor proposal one at a time and address each part of the question one at a time e.g. if a solution looks acceptable, but the stated problem is not clear, then you should provide feedback and make suggestions to improve each prompt before moving on to the next. Avoid responding to all sections of a proposal at once. Move from one question to the next each time asking the contributor to "Please update your original proposal and tag me again when it's ready for review".

4. Limit excessive conversation and moderate issues to keep them on track. If someone is doing any of the following things, please kindly and humbly course-correct them:

- Posting PRs.
- Posting large multi-line diffs (this is basically a PR).
- Skipping any of the required questions.
- Not using the proposal template at all.
- Suggesting that an existing issue is related to the current issue before a problem or root cause has been established.
- Excessively wordy explanations.

5. Choose the first proposal that has a reasonable answer to all the required questions.
-->

[jainilparikh]

Proposal

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

User is able to delete ALL distance rates when application is offline. Expected scenario is that there should be at-least one distance rate and user should NOT be allowed to delete the last remaining distance rate.

What is the root cause of that problem?

Let's assume that there are N distance rates in the list. Since the user is offline, when the user deletes one of the rates, it become's "disabled" but internally it is still considered to be "enabled". Hence, this condition:

 const canDeleteRate = Object.values(customUnit.rates).filter((distanceRate) => distanceRate.enabled).length > 1 || !rate.enabled; 

More specifically:

Object.values(customUnit.rates).filter((distanceRate) => distanceRate.enabled).length

continues to have a value of N and not N - 1. Because of this, when the user attempt's to delete the last rate, since the value of the above condition is still N, canDeleteRate will be false, hence allowing the user to delete the last entry.

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

set enabled as false in optimisticRates and failureRates in deletePolicyDistanceRates function in

https://github.com/Expensify/App/blob/951c7b38e0ec83a876c5e1d24af81e9e6543fc5d/src/libs/actions/Policy.ts#L4792-L4808

What alternative solutions did you explore? (Optional)

Option 2: Adding RED_BRICK_ROAD_PENDING_ACTION in the existing canDeleteRate and canDisableRate conditions

Object.values(customUnit.rates).filter((distanceRate) => distanceRate.enabled && distanceRate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE).length

Option 3: Using a logic similar to what's used in PolicyDistanceRatesPage by creating a allSelectableRates variable.

const allSelectableRates = Object.values(customUnit.rates).filter((rate) => rate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
const canDisableOrDeleteSelectedRates = allSelectableRates.filter((rate: Rate) => rateID !== rate.customUnitRateID).some((rate) => rate.enabled)

The problem with the above approaches however is that it does not solve the root of the problem, i.e setting the enabled flag to false for that rate.

[melvin-bot[bot]]

@slafortune, @sobitneupane Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[sobitneupane]

Will review the proposals shortly.

[sobitneupane]

Thanks for the proposal everyone.

All the proposals are almost same. @Krishna2323 Your proposal needs few refinement. Can you please separate all the options as different solutions in your proposal. You can take this proposal as an example.

Why should we remove pending action add as well? Regarding!rate.enabled, I believe if the rate is disabled there is already an enabled rate (as there is always at least one enabled rate). So, we can safely remove the disabled rate.

[sobitneupane]

Thanks for the proposal @cretadn22

Your proposal looks good to be. Instead of canDisableOrDeleteSelectedRates, let's name the variable canDisableorDeleteRate and I believe simply adding rate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE condition in the following should be enough. https://github.com/Expensify/App/blob/387ab0edd9d2c01c2a0be72950490c94b1b7d9d9/src/pages/workspace/distanceRates/PolicyDistanceRateDetailsPage.tsx#L50

const canDisableorDeleteRate = Object.values(customUnit.rates).filter((distanceRate) => distanceRate.enabled && distanceRate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE).length > 1 || !rate.enabled; 

🎀 👀 🎀 C+ reviewed

[melvin-bot[bot]]

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

[Krishna2323]

@sobitneupane, isn't @cretadn22's proposal same as mine with small refactor?

[sobitneupane]

@Krishna2323 I would say your proposal is rather unclear. You have added multiple things in one place, many of which seem unnecessary.

[Krishna2323]

Remove || !rate.enabled check because user should not be able to delete the receipt until there is one more rate with enabled state. Also, I think we should canDeleteRate and canDisableRate filter out the rates that has pending action value delete.

@sobitneupane, I think this is pretty clear, I mentioned about removing || !rate.enabled check and filtering out with pending action check.

I try to provide solutions for various scenarios because I've encountered situations where the expected outcome changed during discussions, and those who were actively involved at the time took advantage of that.

cc: @tgolen

[jainilparikh]

@sobitneupane , If you were to re-read my solution (https://github.com/Expensify/App/issues/41594#issuecomment-2094095905), it's completely different from the other proposals in the thread. I talk about fixing the root cause i.e. the "disabled" property of the element is not used properly and not just about fixing the UI using rate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE.

I have also explained the same in my proposal from the very beginning.

I think you should re-consider.

CC: @tgolen

[tgolen]

I have read through all the proposals today and I agree with @sobitneupane that the proposal from @cretadn22 is preferrable.

[melvin-bot[bot]]

📣 @cretadn22 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖