[$250] Tag - No error when creating new tag with existing name when tag name has X: Y format

[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: 9.0.5-5
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/4704925
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Workspace settings > Tag
3. Add a tag in X: Y format
4. Click Add tag
5. Attempt to add the same tag in Step 3
6. Note that there is no error that the same tag already exists
7. Create a different tag
8. Click on the tag in Step 7
9. Rename it to the same tag in Step 3 and save it
10. Note that there is no error too and the old tag in Step 7 is gone

Expected Result:

When the tag name has X: Y format, there will be error indicating that the same tag already exists when creating a new tag with the same name (Step 5) and renaming tag to the existing tag name (Step 10)

Actual Result:

When the tag name has X: Y format, no error when creating a new tag with the same name (Step 5) and renaming tag to the same name (Step 10)

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

Bug6536532_1720494570528.bandicam_2024-07-09_11-03-34-672.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0126cdffc6828dd304
• Upwork Job ID: 1811543862318164445
• Last Price Increase: 2024-07-25

Issue Owner

Current Issue Owner: @getusha

[melvin-bot]

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

[lanitochka17]

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

[lanitochka17]

We think that this bug might be related to #wave-collect - Release 1

[bernhardoj]

Proposal

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

There is no tag existing error when trying to add or edit a tag in X: Y format.

What is the root cause of that problem?

When we add a tag in X: Y format, the colon (:) is escaped, so it becomes X\: Y. When we check whether there is an existing tag, we just use the tag name input from the user without escaping it.

App/src/pages/workspace/tags/WorkspaceCreateTagPage.tsx

Lines 48 to 49 in 9c32293

	} else if (tags?.[tagName]) {
	errors.tagName = translate('workspace.tags.existingTagError');

For example, if we input a: b, the tag will be saved as a\: b. When we try to add a: b again, it will check if a: b exists or not which doesn't.

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

Escape the tag name before doing the comparison.

App/src/pages/workspace/tags/WorkspaceCreateTagPage.tsx

Lines 43 to 49 in 9c32293

	const tagName = values.tagName.trim();
	const {tags} = PolicyUtils.getTagList(policyTags, 0);
	if (!ValidationUtils.isRequiredFulfilled(tagName)) {
	errors.tagName = translate('workspace.tags.tagRequiredError');
	} else if (tags?.[tagName]) {
	errors.tagName = translate('workspace.tags.existingTagError');

PolicyUtils.escapeTagName(values.tagName.trim())

We need to do the same for edit tag page.

Also, there is another issue where adding x:y and x\:y tags will show both tags as x:y in the tag list, confusing the user. It's because the code replaces \: or \\: with : from the tag name.

App/src/libs/PolicyUtils.ts

Lines 289 to 291 in 9cd3257

	function getCleanedTagName(tag: string) {
	return tag?.replace(/\\{1,2}:/g, CONST.COLON);
	}

To fix it, we only want to replace \: with :.
tag?.replace(/\\:/g, CONST.COLON);

[devguest07]

Proposal

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

No error when creating new tag with existing name when tag name has X: Y format

What is the root cause of that problem?

When a new tag is added and the tag string contain a colon : the backend will store it on Onyx adding a \ before the colon. So when we add a new tag that contain a colon, we need to check if it exist in the Onyx value. The issue is that the tags on Onyx has a \ added. And currently we are not checking the new tag with the \ similar to what we have stored on Onyx.

We have a function escapeTagName that takes a tag string with : and add the \ to make it similar to the Onyx values. We can use it in the comparisation.

App/src/libs/PolicyUtils.ts

Line 295 in 1534ac2

function escapeTagName(tag: string) {

Below a table with some tests I have done:

• Input: is the value entered on the input form when addinga new tag
• Onyx: how the new tag will be stored on the database
• Escaped: the input value passed throw the escapeTagName function
• Displayed: how the value will be displayed for the user on the tags list page

Test	Input	Onyx	Escaped	Displayed
1	a: a	a\: a	a\: a	a: a
2	b\: b	b\\: b	b\\: b	b: b
3	c\\: c	c\\\: c	c\\\: c	c\: c
4	d\\\: d	d\\\\: d	d\\\\: d	d\\: d

On Test 1, if the user type something in the form of X: Y we can use the escapeTagName to make sure we don't get a duplicate, as we notice from the table, the Onyx value is equal to the Escaped value, same for the input value and the displayed value. So, X: Y will not be repeated.

But on Test 3, if the user type when adding a new tag c\\: c the displayed value will be different. Comparing the escapeTagName with the Onyx value will show that the value already exist but it doesn't. Because the displayed value is not as the one on the input, it's different value c\: c.

So, as we notice, using escapeTagName to compare the Onyx value with the new tag is correct is just some cases where the new tag string have only a colon, but when the user use a colon and lore than a \ in the new tag value , the comparisation using escapeTagName will not be correct. The error will display that those new tag already exists but it doesn't.

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

As mentioned, using escapeTagName to compare the Onyx value with the new tag value will solve only some cases like Test 1 and Test 2, but in more complex examples like Test 3 and Test 4, the comparisation using escapeTagName will display wrong results.

To make a fair comparisation between the value of the new tag and the one displayed using values from Onyx, we should follow a better path. One way to do that is by:

1. Take all the tags from Onyx and convert those values to an array with value similar to the tags displayed
   

   App/src/pages/workspace/tags/WorkspaceCreateTagPage.tsx

   Line 30 in 5ce4e60

   policyTags: OnyxEntry<PolicyTagList>;

As we do for the display, we can use getCleanedTagName to make sure we have the same values as displayed on the tags page.

App/src/pages/workspace/tags/WorkspaceTagsPage.tsx

Line 107 in d576e28

text: PolicyUtils.getCleanedTagName(tag.name),

2. Compare the new tag string to the new tags array:
   Now we have a new array with the same values displayed, we can compare the entered new tag string with those values and make sure no value will be similar to the one from the input.
   

   App/src/pages/workspace/tags/WorkspaceCreateTagPage.tsx

   Line 48 in 5ce4e60

   } else if (tags?.[tagName]) {

What alternative solutions did you explore?

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0126cdffc6828dd304

[melvin-bot]

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