[HOLD for payment 2024-07-22] [$250] Search - "Scanning" appears in Description field when expense is scanning

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.3-1
Reproducible in staging?: Y
Reproducible in production?: N
Found when executing PR : #44190
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition:

• Account has no expenses (or has expenses with no merchant).

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Submit a scan expense.
4. While the expense is scanning, go to Search.

Expected Result:

"Scanning" will not appear in Description field because "Scanning" is not in Description field in transaction thread.

Actual Result:

"Scanning" appears in Description field when "Scanning" is not in Description field in transaction thread.

Workaround:

Unknown

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

Bug6526894_1719536704148.bandicam_2024-06-28_09-01-21-976.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ed996315e0843cef
• Upwork Job ID: 1815474885633659701
• Last Price Increase: 2024-07-22

Issue Owner

Current Issue Owner: @

[melvin-bot]

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

[melvin-bot]

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

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

[izarutskaya]

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

[izarutskaya]

We think this issue might be related to the #collect project.

[izarutskaya]

Production

[etCoderDysto]

Investigating! This seems to come from a PR I have worked on #44190

[cristipaval]

Thanks @etCoderDysto! Assigning you to it

[cristipaval]

@mollfpr, added you as the C+, given that you reviewed the offending PR

[etCoderDysto]

I have identified the issue. I am raising a fixing PR.

In SearchTableHeader we are displaying Description column instead of Merchant. That is because getShouldShowMerchant returns false when item.merchant === "(none)”. 


App/src/components/SelectionList/SearchTableHeader.tsx

Lines 34 to 41 in 1d607ac

	columnName: CONST.SEARCH.TABLE_COLUMNS.MERCHANT,
	translationKey: 'common.merchant',
	shouldShow: (data: OnyxTypes.SearchResults['data']) => SearchUtils.getShouldShowMerchant(data),
	},
	{
	columnName: CONST.SEARCH.TABLE_COLUMNS.DESCRIPTION,
	translationKey: 'common.description',
	shouldShow: (data: OnyxTypes.SearchResults['data']) => !SearchUtils.getShouldShowMerchant(data),

And we are not checking if transactionItem.shouldShowMerchant is true before assigning merchant = translate('iou.receiptStatusTitle’) or 'Scanning...';. transactionItem.shouldShowMerchant is calculated by the same getShouldShowMerchant. 



App/src/components/SelectionList/Search/TransactionListItemRow.tsx

Lines 112 to 115 in 1d607ac

	let merchant = transactionItem.shouldShowMerchant ? transactionItem.formattedMerchant : description;
	if (TransactionUtils.hasReceipt(transactionItem) && TransactionUtils.isReceiptBeingScanned(transactionItem)) {
	merchant = translate('iou.receiptStatusTitle');

Fix: I will add && transactionItem.shouldShowMerchant to prevent assigning Scanning to merchant here

I am raising a fixing PR now

[Julesssss]

Hey @etCoderDysto & @cristipaval, can you please tag me on the fix PR? I want to cherry-pick this and use it to test something.

[etCoderDysto]

Hey @Julesssss. I will tag you.

[etCoderDysto]

@mollfpr @cristipaval
PR is ready for review.

[luacmartins]

I don't think this needs to be a blocker. So I'll remove the labels

[melvin-bot]

This issue has not been updated in over 15 days. @sakluger, @cristipaval, @mollfpr, @etCoderDysto eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[etCoderDysto]

We can close this. It has been over a week since the pr is deployed to production.

[luacmartins]

Oh I think automation failed here and we still need to process the payment. Updating the issue

[melvin-bot]

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

[melvin-bot]

⚠️ This issue has had its price increased by 4x or more. Please review the issue and ensure the price is correct.

[melvin-bot]

Current assignee @mollfpr is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Upwork job price has been updated to $250

[etCoderDysto]

Oh I think automation failed here and we still need to process the payment. Updating the issue

I don't think there are any payments to be made here. This issue was a regression from my PR. And I and C+ fixed the issue.

[luacmartins]

Ah I see, then yes we're good to close since that'll be handled in the original issue. Thank you!