[HOLD for payment 2024-02-20] [$500] [MEDIUM] IOU - Inconsistency of disabled category and tag message

[lanitochka17]

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.25-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): sustinov@applausemail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

Preconditions:
In OldDot under admin, create a Collect group policy, enable Categories and Tag, add 3 Categories and 3 Tag, add an employee to the policy

1. Open https://staging.new.expensify.com/
2. Log in to the employee's account
3. Tap on the green plus button (FAB)
4. Select Request money
5. Select any currency and amount
6. Click next
7. Choose a WS room
8. Click on "Show more"
9. In the "Category" section, select any category
10. In the "Tag" section, select any tag
11. Complete the IOU
12. Open https://staging.expensify.com/
13. Log in to the admin account
14. Navigate to the Collect group policy settings
15. In the category tab, disable the employee's selected category from step 9
16. In the Tag tab, disable the employee's selected tag from step 10
17. In the employee's account in ND, open the IOU details

Expected Result:

The message from the disabled Category and Tag should have the same appearance

Actual Result:

The message from the disabled Category and Tag are different

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c3be1122ebca12e5
• Upwork Job ID: 1747275792072568832
• Last Price Increase: 2024-01-16
• Automatic offers:
• neonbhai | Contributor | 28104172
• s77rt | Contributor | 28104173

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @luacmartins (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[neonbhai]

Proposal

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

Inconsistency of disabled category and tag message

What is the root cause of that problem?

This comes from the copy here:

App/src/languages/en.ts

Lines 2117 to 2119 in d5f0f6f

	tagOutOfPolicy: ({tagName}: ViolationsTagOutOfPolicyParams) => `${tagName ?? ''} no longer valid`,
	taxAmountChanged: 'Tax amount was modified',
	taxOutOfPolicy: ({taxName}: ViolationsTaxOutOfPolicyParams) => `${taxName ?? ''} no longer valid`,

This will also occur for Tax field.

What changes do you think we should make in order

We should update the copy to default to Tax and Tag instead of empty strings

`${tagName ?? 'Tag'} no longer valid`

`${taxName ?? 'Tax'} no longer valid`

[mountiny]

Dont think this has to be a blocker, minor issue. Adding to wave 6 project

[melvin-bot]

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

[luacmartins]

@neonbhai your proposal looks good. Assigning you to the issue.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

📣 @neonbhai 🎉 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 📖

[melvin-bot]

📣 @s77rt 🎉 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 📖

[s77rt]

@luacmartins Shouldn't we drop the variables tagName/taxName and always use Tag/Tax respectively, to be consist with categoryOutOfPolicy and customUnitOutOfPolicy

App/src/languages/en.ts

Lines 2082 to 2084 in d5f0f6f

	categoryOutOfPolicy: 'Category no longer valid',
	conversionSurcharge: ({surcharge}: ViolationsConversionSurchargeParams) => `Applied ${surcharge}% conversion surcharge`,
	customUnitOutOfPolicy: 'Unit no longer valid',

[luacmartins]

That's a good point. I think we'd go the other way around and add categoryName and customUnitName to be consistent with tag and tax and be more specific.

Tagging @cead22 for confirmation, since those came from this PR

[s77rt]

Not overdue. @neonbhai is assigned here

[twisterdotcom]

Same:

Not overdue. @neonbhai is assigned here.

@neonbhai any update on this at all?

[neonbhai]

Sorry for the delay, raising PR soon

[cead22]

Assigning to review PR, and submit a backend fix necessary to make this work

[cead22]

The backend fix should be on staging on Monday 🤞

[twisterdotcom]

Still being reviewed: #35048 (comment)

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

• [Violations] Update tagOutOfPolicy and taxOutOfPolicy  #35048

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

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

• @s77rt requires payment automatic offer (Contributor)
• @neonbhai 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:

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

[s77rt]

• The PR that introduced the bug has been identified: Update MoneyRequestView.js to show Violations #32594
• The offending PR has been commented on: Update MoneyRequestView.js to show Violations #32594 (comment)
• A discussion in #expensify-bugs has been started: Not needed (a unique bug)
• Determine if we should create a regression test for this bug: No. This is not a bug that could just resurface

[twisterdotcom]

Payment Summary:

• @s77rt paid $500 here (Contributor+)
• @neonbhai paid $500 here (Contributor)