Expense - scan failure receipt not display red dot in the request preview

[mitarachim]

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: v9.1.25-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: No, reproducible on hybrid only
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5903593
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: iPhone 16 pro/ 18.3.2
App Component: Money Requests

Action Performed:

1. Open app
2. Go to any workspace chat
3. Create an expense with scan a failure receipt
4. Wait scanning completed

Expected Result:

There's a red dot in the request preview

Actual Result:

There isn't red dot in the request preview

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6796921_1744188634733.Qjsu1110_1_.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @youssef-lr

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @youssef-lr (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[nkdengineer]

Proposal

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

There isn't red dot in the request preview

What is the root cause of that problem?

The RBR is removed here unexpectedly

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

We should add this back here

{shouldShowRBR && (
    <Icon
        src={Expensicons.DotIndicator}
        fill={theme.danger}
    />
)}

App/src/components/ReportActionItem/ReportPreview.tsx

Line 625 in a288fa5

{!shouldShowRBR && shouldPromptUserToAddBankAccount && (

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

NA

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

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

• [CP Staging] Revert "Simplified actions on report header" #59931

If no regressions arise, payment will be issued on 2025-04-18. 🎊

[melvin-bot]

@youssef-lr @sonialiap @youssef-lr The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[SzymczakJ]

@luacmartins I noticed there is an report preview inconsistency between old state of the app, where we show RBR dot and our new approach.
Previously we would show RBR when there were any type of violations(because we were using hasViolations, hasNoticeTypeViolations and hasWarningTypeViolations) right now we use only hasViolations wchich results in that we don't show review, when for example we have dupes detected.
I want to confirm, if we need to add hasNoticeTypeViolations and hasWarningTypeViolations to violations check everywhere in report preview utils. That would result in showing "Review" on bulked expenses preview even though only one of these exepnses has violations and we can submit in the header.

Screen.Recording.2025-04-11.at.11.44.28.mov

For reference this is the current behaviour, we don't show the "Review", when the violation is of a warning type.

Screen.Recording.2025-04-11.at.11.48.47.mov

[luacmartins]

@SzymczakJ yes, let's update it to also include hasNoticeTypeViolations and hasWarningTypeViolations. That being said, we shouldn't display the review button if the violation has been resolved, e.g. duplicates.

[jnowakow]

@luacmartins in case of scan violations we should show "Review" or "View" and RBR?

[luacmartins]

Review

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[sonialiap]

@luacmartins Looks like this hasn't been resolved yet, correct?

[luacmartins]

No, it hasn't. I updated the title/labels to reflect that.

[melvin-bot]

@sonialiap Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@youssef-lr Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@youssef-lr 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[jnowakow]

@luacmartins actually this issue was already resolved by @borys3kk or me in one of follow-ups. This is behaviour from current main:

[luacmartins]

Nice! Let's close this issue then.