[HOLD for payment 2024-10-25] [$250] Room-Description with mentions shown in preview but after saved disappeared

[IuliiaHerets]

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.37-0
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Open a room chat
3. Tap header -- description
4. Enter description with mention and save it eg : Hamburger squishes content on mobile web (native?) #233

Expected Result:

Description with mentions shown in preview and must be displayed after saved also.

Actual Result:

Description with mentions shown in preview but after saved shown briefly and disappears.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• [x ] MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6607424_1726644443287.screenrecorder-2024-09-18-10-28-17-734_compress_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021836660554703667076
• Upwork Job ID: 1836660554703667076
• Last Price Increase: 2024-10-03
• Automatic offers:
• rayane-djouah | Reviewer | 104326440
• truph01 | Contributor | 104326443

Issue Owner

Current Issue Owner: @greg-schroeder

[melvin-bot]

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

[IuliiaHerets]

@greg-schroeder 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

[truph01]

Edited by proposal-police: This proposal was edited at 2024-09-19 17:04:09 UTC.

Proposal

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

• Description with mentions shown in preview but after saved shown briefly and disappears.

What is the root cause of that problem?

• When we save description "#123xxx", we sent to BE "<mention-report>#123xxx</mention-report>" but BE returns "#123xxx" - a MD string.

• And shouldParseTitle is not added in this:

App/src/pages/ReportDetailsPage.tsx

Line 729 in 0c618ac

<MenuItemWithTopDescription

while the description returned by BE is a MD string.

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

• When display "#123xxx" we should check if "123xxx" is reportName data of any report in the current policy. If yes, highlight that text.

• First, update:
  

  App/src/pages/ReportDetailsPage.tsx

  Line 729 in 0c618ac

  <MenuItemWithTopDescription

                           <MentionReportContext.Provider value={mentionReportContextValue}>
                                <MenuItemWithTopDescription ... />
                           </MentionReportContext.Provider> 

  const mentionReportContextValue = useMemo(() => ({currentReportID: report.reportID, exact: true}), [report.reportID]);

• Second, update:

App/src/pages/RoomDescriptionPage.tsx

Line 82 in ace39e8

<InputWrapper

                            excludedMarkdownStyles={isReportInGroupPolicy ? ['mentionReport'] : []}

with:

    const isReportInGroupPolicy = !!report?.policyID && report.policyID !== CONST.POLICY.ID_FAKE;

to make sure the reportMentions markdown is only applied if the current report belongs to policy.

• Finally, update this:

App/src/components/HTMLEngineProvider/HTMLRenderers/MentionReportRenderer/index.tsx

Line 89 in ace39e8

isGroupPolicyReport

to:

                        isGroupPolicyReport && (!exact || navigationRoute)

What alternative solutions did you explore? (Optional)

See

Fix the description preview

• We should update that MenuItemWithTopDescription to:

+                          <MentionReportContext.Provider value={mentionReportContextValue}>
                                <MenuItemWithTopDescription
+                                  shouldParseTitle
-                                  shoudlRenderAsHTML
+                                 excludedMarkdownRules={!policy ? ['reportMentions'] : []}
                                />
+                          </MentionReportContext.Provider>

+  const mentionReportContextValue = useMemo(() => ({currentReportID: report.reportID}), [report.reportID]);

Fix the description's form

• Next, we need to fix the RoomDescriptionPage so that it will send the markdown data to BE instead of HTML.

• First, update:

App/src/pages/RoomDescriptionPage.tsx

Line 36 in 0c618ac

const [description, setDescription] = useState(() => Parser.htmlToMarkdown(report?.description ?? ''));

    const [description, setDescription] = useState(report?.description ?? '');

• Last, update:
  

  App/src/libs/actions/Report.ts

  Line 2053 in 0c618ac

  const optimisticDescriptionUpdatedReportAction = ReportUtils.buildOptimisticRoomDescriptionUpdatedReportAction(parsedDescription);

    const parsedDescription = Parser.htmlToMarkdown(ReportUtils.getParsedComment(newValue, {reportID}));

[melvin-bot]

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

[melvin-bot]

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

[FitseTLT]

This is not a bug. If we mention a correct room the BE sets the description to the mention of that room and it is a correct clickable mention but if the BE doesn't get a room with that name it will consider it a normal text so the mention will disappear. In compose we have a option to deal with this case with a whisper message explaining that the room doesn't exist and ask if the user wants to create it but in this case I think it is unnecessary.

[truph01]

@greg-schroeder Can you confirm the expected behavior here? In the preview, should we always highlight the text #any-text, or we just highlight it if #any-text is the reportName of the existing report?

[truph01]

Proposal updated

[rayane-djouah]

Will review this in my morning 👍

[truph01]

@greg-schroeder Can you confirm this comment?

[rayane-djouah]

@Expensify/design Could you please clarify the expected behavior here?

[dubielzyk-expensify]

Looks like this is an issue on the main intro chat message too:

CleanShot.2024-09-26.at.10.45.55.mp4

Since we respect all other forms of mention (user name) and links (urls), I kinda feel like we should respect the room mentions too, but it being unhighlighted makes me wonder if this is a deliberate decisions. Let's loop in @JmillsExpensify , @trjExpensify and @dannymcclain to hear if they know why this is happening. Otherwise I'd say that we should respect the mention of other rooms in the same way we do URLs and users.

[truph01]

@dubielzyk-expensify FYI, we only highlight #xxx if xxx refers to an existing room. Otherwise, it's treated as regular text. The chat message serves as the correct reference for use in other sections.

The issue we're facing here (see video) is that after saving the room description with the #... syntax, the text following the # is briefly highlighted but then reverts to regular text.

[dubielzyk-expensify]

Ahh right. I see what you mean. I don't think this is a huge deal then, but if we can understand that this isn't actually a room before we save and preview it, then that'd be ideal. So that we don't end up with this flicker

[truph01]

if we can understand that this isn't actually a room before we save and preview it, then that'd be ideal. So that we don't end up with this flicker

Yeah, my solution follows this approach.

[dannymcclain]

if we can understand that this isn't actually a room before we save and preview it, then that'd be ideal. So that we don't end up with this flicker

Totally agree. 👍

[trjExpensify]

^^ samesies.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@greg-schroeder, @rayane-djouah Eep! 4 days overdue now. Issues have feelings too...

[rayane-djouah]

Thanks for confirming the expected result! will review the existing proposal today

[melvin-bot]

@greg-schroeder @rayane-djouah this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[rayane-djouah]

@truph01 Do you have a test branch for the suggested changes?

[truph01]

@rayane-djouah The test branch here

[rayane-djouah]

@truph01 The RCA and solution make sense to me. (The proposal suggests applying the mention styles only when the mention data has a corresponding report ID.)

Is it possible to also fix the bug related to the room description on the report page and to the set the room description to: action message using the same approach?

Screen.Recording.2024-10-07.at.8.11.42.PM.mov

[truph01]

Is it possible to also fix the bug related to the room description on the report page and to the set the room description to: action message using the same approach?

• I believe it's possible, but doing so would expand the scope of the issue.

• In general, we need to update the function:

App/src/libs/ReportUtils.ts

Line 4164 in fb4e24e

function getParsedComment(text: string, parsingDetails?: ParsingDetails): string {

Currently, we only set disabledRules: reportMentions if it is not policy report:

App/src/libs/ReportUtils.ts

Line 4181 in fb4e24e

? Parser.replace(textWithMention, {shouldEscapeText: parsingDetails?.shouldEscapeText, disabledRules: isGroupPolicyReport ? [] : ['reportMentions']})

that leads to the bug you mentioned above. To fix it, we need to make sure we also set disabledRules: reportMentions if the mention data has a corresponding report ID.

[rayane-djouah]

@truph01's proposal looks good to me

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

📣 @rayane-djouah 🎉 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]

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

[truph01]

PR is ready

[greg-schroeder]

@rayane-djouah is up for review!

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

• fix: Description with mentions shown for a while after saving #50490

If no regressions arise, payment will be issued on 2024-10-25. 🎊

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

• @rayane-djouah requires payment automatic offer (Reviewer)
• @truph01 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:

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

[rayane-djouah]

BugZero Checklist

• The PR that introduced the bug has been identified. Link to the PR: Missed case in feature implementation Adds support for mentions in room description #45352
• 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: Adds support for mentions in room description #45352 (comment)
• 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

1. Open a room chat.
2. Tap the header > description.
3. Enter a description with a room mention (ensure that the mentioned room does not exist).
4. Click on "Save."
5. Verify that the room mention is not highlighted in the description preview.
6. Open a room chat again.
7. Tap the header > description.
8. Enter a description with a room mention (ensure that the mentioned room exists).
9. Verify that the room mention is highlighted in the description preview.

Do we agree 👍 or 👎

[greg-schroeder]

Payment summary:

Contributor: @truph01 - $250 via Upwork
C+: @rayane-djouah - $250 via Upwork