[$250] Tag - Disabled "Region" not shown in confirmation page but displayed after creating expense

[izarutskaya]

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: 9.0.10
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4751882
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Pre-condition: Admin -Have a workplace with tags enabled. Have a member invited as employee.
In old dot, upload dependant tags. ( Make sure to enable multiple level tags and uptick independent tags)

1. Launch app
2. Login as admin
3. Tap profile icon -- workspaces -- workspace
4. Tap tag - Region
5. Tap Name selector and disable all tags using above caret dropdown
6. In mweb, login as employee
7. Open workspace chat
8. Tap plus icon -- submit expense
9. Enter an amount and tap next
10. Enter merchant
11. Tap show more
12. Note "Region" field not displayed
13. Tap Submit
14. Open the newly created expense
15. Note "Region" option displayed

Expected Result:

Disabled "Region" tag is not shown in confirmation page and so must not be displayed after creating distance.

Actual Result:

Disabled "Region" tag is not shown in confirmation page but displayed after creating distance.

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

Bug6549075_1721631628613.gt.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a4446baaccd96a5f
• Upwork Job ID: 1821192541013893497
• Last Price Increase: 2024-08-07
• Automatic offers:
• paultsimura | Reviewer | 103495103
• FitseTLT | Contributor | 103495104

Issue Owner

Current Issue Owner: @paultsimura

[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 #vip-vsb

[FitseTLT]

Proposal

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

Tag - Disabled "Region" not shown in confirmation page but displayed after creating expense

What is the root cause of that problem?

We are not checking if there are enabled tags before displaying in MoneyRequestView as we do in confirmation

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 448 to 449 in b8b99d0

	const shouldShow = shouldShowTags && (!isMultilevelTags || OptionsListUtils.hasEnabledOptions(tags));
	return {

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

We need to include a check we use in confirmation page like here

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 448 to 449 in b8b99d0

	const shouldShow = shouldShowTags && (!isMultilevelTags || OptionsListUtils.hasEnabledOptions(tags));
	return {

We should first determine shouldShow tag by changing

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 363 to 364 in b8b99d0

	const tagList = policyTagLists.map(({name, orderWeight}, index) => {
	const tagError = getErrorForField(

 const isMultilevelTags = useMemo(() => PolicyUtils.isMultiLevelTags(policyTagList), [policyTagList]);

    const tagList = policyTagLists.map(({name, orderWeight, tags}, index) => {
        const shouldShow = shouldShowTag && (!isMultilevelTags || OptionsListUtils.hasEnabledOptions(tags));

and only display the specific tag menu when the tag has an enabled tags otherwise return null

---

But if the transaction had a tag selected with the disabled multi-level tag type we might need to display the menu but disable the interactiveness, in that case we can disable interactiveness when TransactionUtils.getTagForDisplay(transaction, index) isEmpty and update the shouldShow so that it is true if it (transactionTag on the specific multi-level tag) is non empty

        const shouldShow = shouldShowTag && (!isMultilevelTags || OptionsListUtils.hasEnabledOptions(tags) || !isEmpty(TransactionUtils.getTagForDisplay(transaction, index)));

What alternative solutions did you explore? (Optional)

[melvin-bot]

@JmillsExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@JmillsExpensify Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@JmillsExpensify 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[melvin-bot]

@JmillsExpensify 10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot]

@JmillsExpensify this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

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

[JmillsExpensify]

Added to wave-collect as polish and opening up for reviews.

[melvin-bot]

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

[paultsimura]

The proposal by @FitseTLT looks good to me.

🎀👀🎀 C+ reviewed

With only one suggestion:

But if the transaction had a tag selected with the disabled multi-level tag type we might need to display the menu but disable the interactiveness, in that case we can disable interactiveness when TransactionUtils.getTagForDisplay(transaction, index) isEmpty and update the shouldShow so that it is true if it (transactionTag on the specific multi-level tag) is non empty

I don't think we should make the field non-interactive in this case. We may want to allow the user to remove the tag value one last time:

2024-08-07.-.18.16.-.Screen.Recording.2024-08-07.at.18.16.40.mp4

WDYT about this @JmillsExpensify?

[melvin-bot]

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

[trjExpensify]

Looking at the OP, this issue confused me initially. The tester has configured dependent multi-tags on OldDot. We don't officially support that or manual configuration of multi-tags on NewDot collect.

I was worried we were just going to hack solutions to fix bugs for dependent multi-tags and this should be in a #wave-control doc down the line to properly support them on that plan or something.

A more appropriate test for what's supported on collect in NewDot would be to:

• Connect QBO
• Import two levels of coding as tags
• Confirm they both show up on the confirmation page when submitting an expense on that workspace
• Disable all of the values on one of the imported tag lists
• Confirm the disabled level doesn't show on the confirmation page
• Confirm the disabled level doesn't show on the created expense

Seems like we still have this bug, so it's not limited to handling dependent multi-tags, so that's good:

2024-08-08_16-15-23.mp4

I don't think we should make the field non-interactive in this case. We may want to allow the user to remove the tag value one last time

I agree with this. If there's a value selected, we shouldn't disable it or not show it. If they do deselect the selected value, then we can not show it. 👍

[melvin-bot]

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

Offer link
Upwork job

[melvin-bot]

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

[paultsimura]

Not overdue – just got the Contributor assigned.

[paultsimura]

The PR has been reviewed, but we need to hold for #47687 for it to be tested on one more case.

[paultsimura]

This was deployed to production in v9.0.26-6.
Payment is due 2024-09-06.

[paultsimura]

• The PR that introduced the bug has been identified. Link to the PR: N/A – it was missed during the initial Tags feature development.
• 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: N/A
• 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
• Determine if we should create a regression test for this bug: Yes
• 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

Pre-condition:

• In OD, upload dependent multi-level Tags

Test:

1. In ND, disable all tags of one level of the multi-level tags (e.g. Region) in a workspace
2. Start submitting an expense on this workspace
3. Verify that on the confirmation page, the tag level (of which you have disabled all tags in (1)) is not present in the tag lists
4. Fill in other tag levels with values
5. Submit the request
6. Open the transaction details view of the said expense
7. Verify that similar to the confirmation page, the tag level (of which you have disabled all tags in (1)) is not present in the tag lists
8. Go to the workspace settings
9. Disable all the values of another tag level (for which you have entered the value on the expense, e.g. "City")
10. Open the transaction details view of the said expense once again
11. Verify the "City" tag is present, but in allows only de-selecting the selected value
12. Click "City" and de-select the value
13. Verify the "City" tag is no longer present on the transaction view page as all its values are disabled now.

Do we agree 👍 or 👎

[paultsimura]

FYI @JmillsExpensify – the payment is due tomorrow.

[JmillsExpensify]

Payment summary:

• Contributor: @FitseTLT $250
• Reviewer: @paultsimura $250

[melvin-bot]

This issue has not been updated in over 15 days. @JmillsExpensify, @paultsimura, @FitseTLT, @stitesExpensify eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[paultsimura]

@JmillsExpensify can this be closed?

[FitseTLT]

@JmillsExpensify I think we can close this issue. 👍

[JmillsExpensify]

Thanks, closing this one out.