RBR transaction thread is disappearing from the LHN when navigating to another chat

[tienifr]

Details

Fixed Issues

$ #36778
PROPOSAL: #36778 (comment)

Tests

Prerequisite: violations is in betas, or all betas is enable

1. have an expense that you are the submitter on, which has violations
2. go to the transaction thread
3. notice that you see violations on the expense and that the RBR is shown in the LHN
4. navigate to a different chat
5. Verify that: the RBR chat stays "pinned" in the LHN as long as the RBR is present

• Verify that no errors appear in the JS console

Offline tests

Same as above

QA Steps

Prerequisite: violations is in betas, or all betas is enable

1. have an expense that you are the submitter on, which has violations
2. go to the transaction thread
3. notice that you see violations on the expense and that the RBR is shown in the LHN
4. navigate to a different chat
5. Verify that: the RBR chat stays "pinned" in the LHN as long as the RBR is present

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Screen.Recording.2024-05-24.at.10.55.56.mov

Android: mWeb Chrome

Screen.Recording.2024-05-24.at.10.51.46.mov

iOS: Native

Screen.Recording.2024-05-24.at.10.55.43.mov

iOS: mWeb Safari

Screen.Recording.2024-05-02.at.22.34.38.mov

MacOS: Chrome / Safari

web-resize.mp4

MacOS: Desktop

Screen.Recording.2024-05-24.at.10.53.47.mov

[melvin-bot]

@jjcoffee Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[tienifr]

@jjcoffee Did you face the following problem on Desktop/mweb

1. Enable Members must categorize all spend on any WS
2. Go to that WS and create the request money without category
3. Go to the detail transaction page
4. The RBR is not shown on category option

It worked well on macos web chrome

web-resize.mp4

[jjcoffee]

@tienifr Hmm it might be a known issue. Does it happen for all violations? I'll try and get this tested by Monday.

[tienifr]

@jjcoffee I just tested the case when RM didn't have the category

it might be a known issue

Do you remember the known issue?

[jjcoffee]

@tienifr I think you just need to enable the violations beta in Permissions.ts.

[jjcoffee]

@tienifr This doesn't seem to work for me. With most recent mode:

desktop-chrome-2024-05-06_12.02.05.mp4

With focus mode:

desktop-chrome-2024-05-06_12.38.19.mp4

[tienifr]

@jjcoffee I found out other problem in

App/src/libs/SidebarUtils.ts

Line 90 in e0b6a06

betas?.includes(CONST.BETAS.VIOLATIONS) &&

our betas doesn't have violations that make the above condition fail. To add violations to betas we need BE help.

[tienifr]

@jjcoffee can you help check the comment above

[jjcoffee]

@tienifr Sorry I'm not sure I understand what you're asking, can you provide some more detail?

[tienifr]

@jjcoffee Let's check the image below. It's the betas value returned from BE and it doesn't contain violations

That causes the condition failed

App/src/libs/SidebarUtils.ts

Line 90 in e0b6a06

betas?.includes(CONST.BETAS.VIOLATIONS) &&

-> doesReportHaveViolations is always false for every report

In my proposal, we want to show the report if doesReportHaveViolations is true

It's the inconsistency.

[tienifr]

Beside, the logic to show the red dot dees not include that check so we can see the red dot, but doesReportHaveViolations is still false -> That's incorrect

[jjcoffee]

@tienifr Ah I think I see what you mean, but we can't just ask to enable the violations beta for all users 😄 Can we reuse the logic that's used for displaying the RBR dot?

[tienifr]

@jjcoffee yah, I think it's added on purpose. @AndrewGable Can you help check the above concern? Thanks

[AndrewGable]

Asked @cead22 for more details on when the violations beta will be enabled for all users.

Otherwise @jjcoffee's recommendation seems OK:

Can we reuse the logic that's used for displaying the RBR dot?

[jjcoffee]

@tienifr Not sure if this is ready for re-review or not, but there's a failing jest test.

[tienifr]

@jjcoffee I fixed the test failed. It's ready for review

[AndrewGable]

FYI violations beta should be removed in ~2 weeks

[jjcoffee]

@tienifr Can you confirm if the violations beta needs to be enabled in order for this to work? I don't seem to see any difference from this.

[tienifr]

@jjcoffee I used canUseViolations (that will be true if canUseAllBetas true) instead of checking betas?.includes(CONST.BETAS.VIOLATIONS). Did you enable canUseAllBetas (maybe hard code)?

[jjcoffee]

@tienifr Ah gotcha, thanks! Can you update the test steps to include that the beta needs to be enabled?

[tienifr]

@jjcoffee Updated!

[tienifr]

I updated the videos

[jjcoffee]

Currently, we're sorting by name

Okay I guess we can leave that for now then!

[jjcoffee]

Thanks for persevering with this! Tests well and LGTM 🚀

[tienifr]

@cead22 Thanks for your feedback. I updated the PR

[tienifr]

@cead22 any updates?

[cead22]

This is waiting for @AndrewGable 's review

[cead22]

Fail fast?

if (!parentReportAction) {
    return false;
}
...

[tienifr]

I think they're the same. If parentReportAction is false, shouldDisplayTransactionThreadViolations won't run. ANW, I updated the PR as your suggestion. Thanks

[cead22]

Yup, the idea behind failing fast isn't to change functionality, but to make functions easier to parse/read

[jjcoffee]

@AndrewGable Friendly bump for review 🙇

[AndrewGable]

@tienifr - Conflicts

[tienifr]

@AndrewGable I resolved the conflicts. We're good to go

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[luacmartins]

FYI I'm reverting this PR because it caused these blockers:

• Expense - Duplicate transaction threads with RBR in LHN when sending expense to each other #43252
• [HOLD for payment 2024-07-22] [HOLD for payment 2024-07-17] Expense - Header subtitle from report with RBR in LHN leads to the same transaction view  #43238

Please work on this fix again taking into account the issues above

[jjcoffee]

Asking for clarification on #43238 as I'm not 100% on the expected result.

@tienifr Are you able to take a look at #43252?

[luacmartins]

@jjcoffee left a comment on #43238

[OSBotify]

🚀 Deployed to production by https://github.com/luacmartins in version: 1.4.81-11 🚀

platform	result
🤖 android 🤖	failure ❌
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅