[HOLD] Stop highlighting report mentions in non policy rooms in the Composer

[rlinoz]

Problem:
While typing a report mention in the composer in a DM or group chat the mention is highlighted, even though it is not possible to mention a report in this types o chats.

Solution:
We need to stop applying the markdown style to report mentions in reports that don't belong to a group policy.

[ShridharGoel]

Proposal

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

Need to stop highlighting report mentions in non policy rooms.

What is the root cause of that problem?

As of now, mentionReport is always using theme.mentionText and theme.mentionBG in the markdown style which leads to the highlighting.

App/src/hooks/useMarkdownStyle.ts

Lines 52 to 55 in ab1e924

	mentionReport: {
	color: theme.mentionText,
	backgroundColor: theme.mentionBG,
	},

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

We'll add a new argument to useMarkdownStyle.

function useMarkdownStyle(message: string | null = null, shouldUseMentionReport = true)

Updated logic for styles of mentionReport:

mentionReport: {
    color: shouldUseMentionReport ? theme.mentionText : null,
    backgroundColor: shouldUseMentionReport ? theme.mentionBG : null,
},

Pass isGroupPolicyReport as a prop to Composer via ComposerWithSuggestions.

isGroupPolicyReport={isGroupPolicyReport}

We'll update Composer function signature in both index.tsx and index.native.tsx.

Now, we can pass the same to useMarkdownStyle as the value of shouldUseMentionReport by updating this code: Link.

const markdownStyle = useMarkdownStyle(value, isGroupPolicyReport);

We'll do the same in index.native.tsx also:

App/src/components/Composer/index.native.tsx

Line 37 in ab1e924

const markdownStyle = useMarkdownStyle(value);

[robertKozik]

Hi @rlinoz! I'll look into it

[nkdengineer]

Proposal

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

• Stop highlighting report mentions in non policy rooms in the Composer

What is the root cause of that problem?

• In here, we apply the mentionReport style without checking if the report belongs to policy or not, that leads to 2 bug:

1. Main bug in this issue: While typing a report mention in the composer in a DM or group chat the mention is highlighted, even though it is not possible to mention a report in this types o chats.

2. In policy room chat, when typing any room name that does not belong to the policy, the typed text is still highlighted. Then send a message. That message is still highlighted until the API AddComment is successful.

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

• We should create a new function to check if the typed text matches the suggestedMentions.

• For example, assume that the suggestedMentions contains a few options: [announce, admin, room-1, room-2, room-3] then if user types #room-1, the typed text is highlighted.

  If user types room-4, the typed text is not highlighted because there is no option is room-4.

• Here is the implementation:

1. Create a function:

function doesRoomExisted(roomName: string, listRoomName: string[]) {
    return listRoomName.includes(roomName);
} 

which its inputs are the roomName and listRoomName, and return the boolean value to know if the given room named belongs to the current policy or not . In there above example, doesRoomExisted('room-1', ['announce', 'admin', 'room-1', 'room-2', 'room-3']) returns true

2. Then update this to:

            mentionReport: doesRoomExisted(message, listRoomName) ? {
                color: theme.mentionText,
                backgroundColor: theme.mentionBG,
            }: {},

this step is straightforward so I do not implement the details. The main idea of this step is we will check if the typed text exists in the list room that can be mentioned. If true, apply the highlight style.
Also, we need to apply the change in .native.ts file

3. Now our main bug is fixed. But there is another issue that I mentioned in the RCA section. For example in the above example is room-4, that message is highlighted for a while before the AddComment is called successfully. It is because in here, we apply the mention-report tag in case of isGroupPolicyReport. We should use doesRoomExisted along with doesRoomExisted

What alternative solutions did you explore? (Optional)

• NA

[nkdengineer]

I updated the proposal

[rlinoz]

Sorry we aligned on Slack that this one should go to Robert since he was the one adding the styling to report mentions.

[nkdengineer]

@rlinoz I found another related bug: In policy room chat, when typing any room name that does not belong to the policy, the typed text is still highlighted. Then send a message. That message is still highlighted until the API AddComment is successful.

Can you confirm if it is a bug? Thanks

[robertKozik]

Hi @nkdengineer I think it's not actually a bug - If there is no rrom with such a name, we will send actionable whisper with an option to create it. Checking for the room existance is not a valid one in this case. CMIIW

[nkdengineer]

we will send actionable whisper with an option to create it

@robertKozik This feature is not implemented in staging, right? (So I think It will be handled in the future).

Thanks for your information!

[robertKozik]

I believe frontend implementation is already merged, only backend part is not yet in staging. But I'm not so up-to-date on it 😄

[robertKozik]

@rlinoz I've created draft PR for this one. I went with more general solution and implement the rule excluding mechanism. Feel free to test and comment - I'll add the remaining screenshots and the rest later today.

[melvin-bot]

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

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

• add possibility of excluding styles in useMarkdownStyles #41731

If no regressions arise, payment will be issued on 2024-06-03. 🎊

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

• @robertKozik does not require payment (Contractor)

[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.

[rlinoz]

@JmillsExpensify @mollfpr reviewed the PR.

[rlinoz]

Checking if we should close here #42523 (comment)

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @mollfpr owed $250 via NewDot
• Contributor: @robertKozik is from an agency-contributor and not due payment

BugZero Checklist (@JmillsExpensify)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants//hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[SzymczakJ]

The PR that solved this issue was reverted. I'll be taking care of this issue now 😄

[rlinoz]

Just to be sure we are waiting on this PR? Expensify/react-native-live-markdown#366

[SzymczakJ]

Correct. There is a lot going on in react-native-live-markdown, so we will have to wait , but I'm pinging react-native-live-markdown team to merge this fix ASAP 😄

[SzymczakJ]

Fix was merged into react-native-live-markdown so I'm putting the reverted PR back, but let us merge bump of react native live markdown in a separate PR, because it fixes A LOT of other issues. This should get merged pretty easily and in the meantime we can test this PR.