[$500] IOU - Show more dropdown option not displayed and manual displayed for scan option

[lanitochka17]

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: 1.3.90-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. Click the FAB button > Request Money
2. Select the "Scan" option
3. Upload a receipt
4. The Description, Date, Merchant details are displayed (not hidden under a "Show More" section)
5. Now, FAB button > Request Money > Manual > set an amount
6. Notice the Description, Date, Merchant are hidden under a "Show More" section

Expected Result:

"Show more" drop down option is displayed when manually creating an expense and when scanning a receipt

Actual Result:

"Show more" dropdown not displayed when Scanning a receipt but is displayed when manually creating an expense

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Desktop

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

Windows: Chrome

Bug6249467_1698185995220.show_more.mp4

MacOS: Desktop

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0141550f3d1c8d39d8
• Upwork Job ID: 1716962535050149888
• Last Price Increase: 2023-10-31

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @Christinadobrzyn (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[marktoman]

Proposal

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

When requesting money in a workspace by scanning a receipt, the fields that are intended to be hidden are visible and the header title is incorrect.

What is the root cause of that problem?

Property shouldShowSmartScanFields is used incorrectly. It was intended to show date, merchant, and amount. This is not the case, however, as those fields are not conditioned by the flag. As it is currently, the shouldShowSmartScanFields negates the actual flag that controls the fields.

App/src/components/MoneyRequestConfirmationList.js

Line 586 in 3651a16

{props.shouldShowSmartScanFields && (

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

1. Rename the flag to reflect what it does (e.g. shouldShowAmount, it isn't scan specific) as it doesn't control date and merchant
2. Remove the flag from here so it doesn't affect the other fields

   App/src/components/MoneyRequestConfirmationList.js

   Line 235 in 3651a16

   const shouldShowAllFields = props.isDistanceRequest || shouldExpandFields || !props.shouldShowSmartScanFields || isTypeSend || props.isEditingSplitBill;

3. Reflect it here by changing it to props.shouldShowAmount. (Amount is intended to be hidden in this flow when receiptPath is empty )
4. Fix the header title by extending this line and headerTitle here so if isScanRequest is true, it translates to "Scan" in the header

What alternative solutions did you explore? (Optional)

Option 1. Keep shouldShowSmartScanFields as is, but copy the date and the merchant fields as they are under the shouldShowAllFields flag and duplicate them under shouldShowSmartScanFields so the flag controls them.

App/src/components/MoneyRequestConfirmationList.js

Line 586 in 3651a16

{props.shouldShowSmartScanFields && (

Option 2. (Workaround) Call to MoneyRequestConfirmationList hides the fields only when props.iou.receiptPath is empty.

App/src/pages/iou/steps/MoneyRequestConfirmPage.js

Line 385 in ca51f6f

shouldShowSmartScanFields={_.isEmpty(props.iou.receiptPath)}

Make the call unconditional like in the other flow.

[dukenv0307]

Proposal

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

Show more dropdown option not displayed and manual displayed for scan option

What is the root cause of that problem?

1. We don't have the case to return Scan in the header
   

   App/src/pages/iou/steps/MoneyRequestConfirmPage.js

   Lines 310 to 325 in 1c85ebe

   	const headerTitle = () => {
   	if (isDistanceRequest) {
   	return props.translate('common.distance');
   	}
   	if (iouType.current === CONST.IOU.TYPE.SPLIT) {
   	return props.translate('iou.split');
   	}
   	if (iouType.current === CONST.IOU.TYPE.SEND) {
   	return props.translate('common.send');
   	}
   	return props.translate('tabSelector.manual');
   	};

2. For receipt request, shouldShowSmartScanFields is false because receiptPath is not empty
   

   App/src/pages/iou/steps/MoneyRequestConfirmPage.js

   Line 385 in 1c85ebe

   shouldShowSmartScanFields={_.isEmpty(props.iou.receiptPath)}

That makes shouldShowAllFields is true and then Show more button doesn't appear

App/src/components/MoneyRequestConfirmationList.js

Line 235 in 1c85ebe

const shouldShowAllFields = props.isDistanceRequest || shouldExpandFields || !props.shouldShowSmartScanFields || isTypeSend || props.isEditingSplitBill;

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

1. We should add a case to return Scan in header

if (props.iou.receiptPath) {
    return props.translate('tabSelector.scan')
}

App/src/pages/iou/steps/MoneyRequestConfirmPage.js

Lines 310 to 325 in 1c85ebe

	const headerTitle = () => {
	if (isDistanceRequest) {
	return props.translate('common.distance');
	}
	if (iouType.current === CONST.IOU.TYPE.SPLIT) {
	return props.translate('iou.split');
	}
	if (iouType.current === CONST.IOU.TYPE.SEND) {
	return props.translate('common.send');
	}
	return props.translate('tabSelector.manual');
	};

2. We can remove the check !props.shouldShowSmartScanFields here

const shouldShowAllFields = props.isDistanceRequest || shouldExpandFields || isTypeSend || props.isEditingSplitBill;

App/src/components/MoneyRequestConfirmationList.js

Line 235 in 1c85ebe

const shouldShowAllFields = props.isDistanceRequest || shouldExpandFields || !props.shouldShowSmartScanFields || isTypeSend || props.isEditingSplitBill;

What alternative solutions did you explore? (Optional)

NA

Result

Screen.Recording.2023-10-25.at.10.56.01.mov

[Christinadobrzyn]

I can reproduce this - asking the team if we want to have "Show More" for scanned receipts - https://expensify.slack.com/archives/C01SKUP7QR0/p1698351093452399

[marktoman]

Interestingly, the current behavior is unrelated to the intent of the flags. So, even if all fields should remain visible, the code needs to be fixed to make sense. That would involve an explicit prop added to the shouldShowAllFields condition (with the same name).

[Christinadobrzyn]

Talking this over with the team - it sounds like this is a regression.

The date and merchant shouldn't show on a Scanned receipt.

Not sure how to find the original job, I'll ask QA if they can help. https://expensify.slack.com/archives/C9YU7BX5M/p1698430405972359

[isagoico]

@Christinadobrzyn The issue that the show more option is not displayed for Scan and distance expenses is expected behavior.
The show more button should only display in Manual expenses. I have added a note in this TC to remind the testers that this is expected.

[Christinadobrzyn]

Thank you @isagoico! Okay so it sounds like this is expected - the "Show More" should only show for manually created expenses. Closing this without action.

[marktoman]

@Christinadobrzyn There is more to fix, however, including what is in the report itself.

[marktoman]

@Christinadobrzyn It looks like you recently removed the wrong header mention from the report. Is that not considered an error anymore?

- Show more drop down option displayed and scan displayed in header
+ "Show more" drop down option is displayed when manually creating an expense and when scanning a receipt

[Christinadobrzyn]

Hi @marktoman, sorry I don't do code changes for the Bug Zero team so I'm not sure what that relates to.

For your mention here -

It looks like you recently removed the wrong header mention from the report. Is that not considered an error anymore?

Is that in a PR? Or can you confirm where you are seeing that change?

Also, can you send me a screenshot or video of what you mean by:

There is more to fix, however, including what is in the report itself.

[melvin-bot]

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

[Christinadobrzyn]

hey @marktoman Can you provide more information about what needs to be fixed, including videos or screenshots and the steps to reproduce so we can test? thanks!

[marktoman]

@Christinadobrzyn Oh, there's actually been a recent merge that fixes that part. The report is okay then, but it would be interesting if an engineer with enough authority could look at the code and say that it does not warrant the suggested refactoring. I don't believe that this would be the conclusion at all.

[melvin-bot]

@eVoloshchak, @Christinadobrzyn Huh... This is 4 days overdue. Who can take care of this?

[Christinadobrzyn]

I think if there's refactoring we'll address that at a later point. The point of this GH is to report bugs - we've concluded this isn't a bug and is working as expected. Any 'clean up' will happen at later date!