[$250] Multi-level dependent tags are behaving incorrectly.

[m-natarajan]

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: 9.0.21-3
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: @paultsimura
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1723715190214299

Action Performed:

Pre-requisite: In OD, upload dependent multi-level Tags for a workspace

1. In ND disable all tags of the middle level of the multi-level tags (e.g. Region)
2. Click FAB -> Submit expense -> Manual
3. Enter the value and proceed
4. Select the workspace you've added the tags for
5. Enter Merchant
6. Enter the "State" tag
7. Enter the "City" tag
8. Because of the bug in 7., enter the "City" tag again – this time with a different value
9. Submit the request and navigate to its details
10. Click "Region" tag and de-select the value

Expected Result:

After step 7: The value is set correctly and you can proceed to submit the request
After step 9: Only the "State" and "City" tags are selected
After step 10: The "Region" tag becomes empty

Actual Result:

After step 7: the value is not displayed and the "City" tag is still empty – in fact, the value selected in 7. is set as "Region", which is disabled.
After step 9: Value selected in 7. is set as "Region"
After step 10: The "Region" tag gets replaced with the "City" value, and the "City" tag becomes empty.

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

2024-08-15.-.11_36.-.Screen.Recording.2024-08-15.at.11.35.54.mp4

Recording.472.mp4

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01823e45b6fd3c9331
• Upwork Job ID: 1825578964708268666
• Last Price Increase: 2024-08-19
• Automatic offers:
• situchan | Contributor | 103593731

Issue Owner

Current Issue Owner: @thesahindia

[melvin-bot]

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

[paultsimura]

@Christinadobrzyn FYI this bug was found when testing #45889 – we are currently holding it for this issue.

[FitseTLT]

Edited by proposal-police: This proposal was edited at 2024-08-19 13:00:28 UTC.

Proposal

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

Multi-level dependent tags are behaving incorrectly.

What is the root cause of that problem?

Trying to filter out empty multi level tags on the end of the tags

App/src/libs/IOUUtils.ts

Lines 146 to 147 in bc69605

	.filter((tagItem) => !!tagItem)
	.join(CONST.COLON);

we are filtering out tags in the middle too and here when we select tagIndex 2 tag for instance tagIndex 1 is filtered out so the tagIndex 2 selection will be considered for for tagIndex 1

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

To filter out unnecessary empty tags in the end of the tag we should instead do

while (tagArray.length > 0 && !tagArray[tagArray.length - 1]) {
    tagArray.pop();
}

return tagArray.join(CONST.COLON);

we can also add the trimming .map((tagItem) => tagItem.trim()) code too

What alternative solutions did you explore? (Optional)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01823e45b6fd3c9331

[melvin-bot]

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

[Christinadobrzyn]

Thanks for the update @paultsimura - adding external to have this proposal reviewed.

[FitseTLT]

Same root cause as #47301 It is a regression that should be handled there

[situchan]

Handling in #47301

[melvin-bot]

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

[Christinadobrzyn]

Ah thank you @FitseTLT and @situchan - @situchan I added you to this GH just for tracking.

Can I close this in favor of #47301?

[situchan]

yes, we can close. We'll make sure to test this case in PR.