Chat - Mention containing valid report ID is not clickable and invalid # is not styled

[kbecciv]

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: 1.4.63-7
Reproducible in staging?: y
Reproducible in production?: y
Issue found when executing PR: #39906
Reported: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to chat.
3. Send text containing the following mention with # :

• valid report ID
• invalid report ID
• invalid room name

Expected Result:

Actual Result:

Workaround:

n/a

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

Bug6454714_1713520407882.20240419_174807.mp4

View all open jobs on GitHub

[melvin-bot]

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

[kbecciv]

We think that this bug might be related to #vip-vsb

[kbecciv]

@jliexpensify 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.

[mountiny]

cc @robertKozik @puneetlath

[jliexpensify]

Can't assign @robertKozik until he comments, but have assigned Puneet for this regression.

[robertKozik]

Hi! Looking into it, thanks for pinging me here!

[robertKozik]

I think we have a little misunderstanding there. User is able to mention rooms only by their names. ReportID values are embedded into HTML attributes of mention tag, and are done on the backend side.
While trying to type mention by id, parser will correctly recognise it as proper mention (as numbers are valid room name), but the typed value would be assume as room name.

But I think we can be. more consistent while we are working on optimistic version of the message, as we will want to remove as much as possible jumping between highlighted -> non-highlighted states when getting the response from the backend.

[puneetlath]

Yes, I think we can close. This is just a misunderstanding.