[HOLD for payment 2024-02-26] [$500] [MEDIUM] [Backwards Compatibility] Expense with category can be created when admin disable the same category

[kbecciv]

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.32-2
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:

Precondition:
User is an employee of Collect workspace on Old Dot which has categories set
Steps:

1. On collect workspace chat Employee starts manual request flow
2. On confirmation page select any category
3. Admin disable the same category on Old Dot
4. Employee complete the IOU flow successfully

Expected Result:

Selected category on confirmation page should disappear/error message should be displayed

Actual Result:

User can successfully create the IOU request

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

Add any screenshot/video evidence

Bug6355608_1706263008737.Gravar__1942.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010fa29b3491c11700
• Upwork Job ID: 1750851608721940480
• Last Price Increase: 2024-01-26
• Automatic offers:
• c3024 | Reviewer | 28131001
• dukenv0307 | Contributor | 28131002

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~010fa29b3491c11700

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

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

[kbecciv]

We think that this bug might be related to #wave6-collect-submitters
CC @greg-schroeder

[dukenv0307]

Proposal

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

User can successfully create the IOU request

What is the root cause of that problem?

We're not clearing the transaction.category if the category is already selected in Request Money flow, but then admin disables the category in settings.

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

Clearing the transaction.category by IOU.resetMoneyRequestCategory_temporaryForRefactor(transactionID); if the category is already selected in Request Money flow, but then admin disables the category in settings.

We can check if the transaction.category corresponds to a category that has enabled: false in policyCategories

We can do this in IOURequestStepCategory (in an useEffect), or have a Onyx.connect in a separate util file to listen to policyCategories changes and do the above for the draft transaction.

What alternative solutions did you explore? (Optional)

An alternate UX is that we don't clear the already-selected category, because it might be confusing to the user. Instead we'll set a formError in the MoneyTemporaryForRefactorRequestConfirmationList telling the user that the selected category has been disabled, and request the user to select another category. The error will show up above the button and also in the MenuItemWithTopDescription of the Category on that page.

But this will be based on the same above condition.

[Santhosh-Sellavel]

OOO Next week, So unassigning. Please assign a new C+ Issue here.

cc: @mallenexpensify

[melvin-bot]

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

[mallenexpensify]

@c3024 plz review the proposal above. Thx

[mallenexpensify]

We think that this bug might be related to #wave6-collect-submitters
CC @greg-schroeder

Agree with @kbecciv , added to Wave 6 project, comment if you disagree @greg-schroeder. Thx!

[c3024]

I think the alternative solution is the way to go because before confirming the request we got the details of enabled categories. So, showing the error at category and the confirm button is the better solution.

categoryRequest.mp4

I think we should change the category page as well to include only the enabled categories notwithstanding the earlier selected category.

categoryPage.mp4

Proposal here by @dukenv0307 looks good to me.

🎀 👀 🎀 C+ Reviewed

[c3024]

No internal engineer assigned. 🤔

🎀 👀 🎀 C+ Reviewed

[melvin-bot]

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

[mallenexpensify]

@Gonals plz review when you have a minute.

[greg-schroeder]

@amyevans given you worked on categories - do you know if this was considered or might be handled elsewhere already?

[amyevans]

@amyevans given you worked on categories - do you know if this was considered or might be handled elsewhere already?

Nope as far as I know this is an edge case we didn't consider/handle yet cc @yuwenmemon

[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.42-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix IOU with category can be created when admin disable the same category #35540

If no regressions arise, payment will be issued on 2024-02-26. 🎊

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

• @c3024 requires payment automatic offer (Reviewer)
• @dukenv0307 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:

• [@c3024] The PR that introduced the bug has been identified. Link to the PR:
• [@c3024] 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:
• [@c3024] 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:
• [@c3024] Determine if we should create a regression test for this bug.
• [@c3024] 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.
• [@mallenexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

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

[c3024]

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:

• [@c3024] The PR that introduced the bug has been identified. Link to the PR: This is a case where a user starts a money request flow and before it is completed, the admin removes a category from the policy on Old dot. The user can finish the money request and the money request page shows an error saying "The category is not valid".
  PR of this issue fixed it by resetting the category field if a category field is deleted during the request flow. As such, this is an edge case and no specific PR can be held responsible.
• [@c3024] 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: NA
• [@c3024] 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: Not started because such discussion does not appear to be helpful for these cases.
• [@c3024] Determine if we should create a regression test for this bug. No because this is an edge case and does not appear to affect user experience adversely meaningfully.
• [@c3024] 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. NA

[melvin-bot]

@Gonals, @mallenexpensify, @c3024, @dukenv0307 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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

[mallenexpensify]

Contributor: @dukenv0307 paid $500 via Upwork
Contributor+: @c3024 paid $500 via Upwork.

@c3024 , what's the reason for thinking we don't want a regression test for this?

[c3024]

@mallenexpensify

This happens when a user is at the money request confirm page

and selects a category. Before this user presses the Request button, an admin of the workspace disables the same category from Old Dot.

A user ordinarily stays on this page for a brief time. During that brief period an admin should remove/disable the same category that was chosen by the user for this bug to happen. It appeared to me as a rare case so I felt it does not need a regression test.

[mallenexpensify]

Thanks @c3024 , I agree it's an edge case. QA has a separate list for edge case tests (and design ones) that they only run monthly, I assume we'll want it for that, created an issue.
https://github.com/Expensify/Expensify/issues/377286