[$500] Request money - Merchant field is cleared after changing receipt in confirmation page

[kbecciv]

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: 1.4.4.0
Reproducible in staging?: y
Reproducible in production?: y
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. Navigate to staging.new.expensify.com
2. Go to FAB > Request money > Manual.
3. Enter amount > choose a participant > proceed to confirmation page.
4. On the confirmation page, click three-dot menu > Add a receipt.
5. Click Merchant and enter a merchant.
6. Click three-dot menu > Add a receipt.

Expected Result:

The entered Merchant is preserved.

Actual Result:

The entered Merchant is cleared.

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

Add any screenshot/video evidence

Bug6293241_1701179729342.20231128_172120__1_.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bcba32334ea8b85b
• Upwork Job ID: 1729502580706914304
• Last Price Increase: 2023-12-19

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @peterdbarkerUK (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 - @mollfpr (External)

[FitseTLT]

Proposal

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

Request money - Merchant field is cleared after changing receipt in confirmation page

What is the root cause of that problem?

We are resetting the merchant of the iou to empty string here

App/src/libs/actions/IOU.js

Lines 2901 to 2902 in 70813db

	Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});
	}

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

Merchant is reset whenever we create a new MoneyRequest here

App/src/libs/actions/IOU.js

Lines 2824 to 2825 in 7c16666

	function startMoneyRequest(iouType, reportID = '') {
	resetMoneyRequestInfo(`${iouType}${reportID}`);

to default merchant

App/src/libs/actions/IOU.js

Lines 132 to 133 in 7c16666

	merchant: CONST.TRANSACTION.DEFAULT_MERCHANT,
	category: '',

So after the user went through the creation process and changed the merchant value manually resetting the merchant the user already inserted on receipt uploading is unexpected behavior for the user experience so we shouldn't reset the merchant uncoditionally here

App/src/libs/actions/IOU.js

Lines 2901 to 2902 in 70813db

	Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});
	}

But what we should do is clear the merchant value only on the first receipt selection and if the merchant value is not equal to the default merchant value we reset in resetMoneyRequestInfo to not reset the merchant field when it is set a new value by the user manually.
So before we call setMoneyRequestReceipt in here, here, here and here we determine whether we should reset merchant field according to the logic mentioned above and pass a third parameter to it to reset merchant or not.

        const shouldResetMerchant = _.isEmpty(iou.receiptPath) && iou.merchant === CONST.TRANSACTION.DEFAULT_MERCHANT;
        IOU.setMoneyRequestReceipt(filePath, file.name, shouldResetMerchant);

and Change setMoneyRequestReceipt

function setMoneyRequestReceipt(receiptPath, receiptFilename, shouldResetMerchant = true) {
    Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, ...(shouldResetMerchant && {merchant: ''})});
}

What alternative solutions did you explore? (Optional)

We can also stop resetting the merchant on setting Receipt if we don't have a special reason to clear merchant on Receipt selection 👍
so change it to

function setMoneyRequestReceipt(receiptPath, receiptFilename) {
    Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename});
}

[tienifr]

Proposal

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

Request money - Merchant field is cleared after changing receipt in confirmation page

What is the root cause of that problem?

The RCA is here

App/src/libs/actions/IOU.js

Line 2901 in 935608b

Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});

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

We just need to reset merchant at the first time users upload receipt like what we did here, when they upload receipt later, we should not reset merchant.

To do that we should check if the current receipt path is empty or not, if it's empty, set merchant to empty, otherwise keep the previous merchant

let currentIOU;
Onyx.connect({
    key: ONYXKEYS.IOU,
    callback: (val) => {
        currentIOU = val || {};
    },
});

function setMoneyRequestReceipt(receiptPath, receiptFilename) {
    if(currentIOU.receiptPath){
        Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename});
        return;
    }
    Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});
}

[yh-0218]

Proposal

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

Request money - Merchant field is cleared after changing receipt in confirmation page

What is the root cause of that problem?

App/src/libs/actions/IOU.js

Line 2901 in 935608b

Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});

We set merchant: ''

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

we need to add reset condition as third param here, here, here and here

        IOU.setMoneyRequestReceipt(filePath, file.name, iou. receiptPath);

function setMoneyRequestReceipt(receiptPath, receiptFilename, originReceiptPath) {
    if (!originReceiptPath) {
        Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});
    } else {
        Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename});
    }
}

[FitseTLT]

Updated proposal

[mollfpr]

I don't have any context regarding the reason we reset the merchant value, but it seems important according to the PR #25924.

Adding a new param for setMoneyRequestReceipt gives more flexibility to determine whether we need to reset the merchant value, but for now, I don't think it's necessary.

@Gonals @mountiny Tagging you guys here from #25924. Could you guys help give more context on the reason we reset the merchant field for receipt requests?

[mountiny]

Asking in Slack, its probably because the smartscaning feature expects no merchant provided

[mountiny]

@mollfpr no reason I think then, lets make sure the merchant is not cleared when receipt is added

[mollfpr]

@mountiny Is there a problem with intelligent scanning with the merchant having a value?

lets make sure the merchant is not cleared when receipt is added

Can we safely revert the removed merchant here?

App/src/libs/actions/IOU.js

Lines 2939 to 2941 in 56a368b

	function setMoneyRequestReceipt(receiptPath, receiptFilename) {
	Onyx.merge(ONYXKEYS.IOU, {receiptPath, receiptFilename, merchant: ''});
	}

I notice that from #25924 there's a comment "For the SmartScan to run successfully, we need to pass the merchant field empty to the API", but it's not there anymore.

[mountiny]

@mollfpr you are right, I think Smartscan does not run if Merchant is provided, that is intentional, still discussing internally.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@peterdbarkerUK, @mollfpr Eep! 4 days overdue now. Issues have feelings too...

[mountiny]

@mollfpr @peterdbarkerUK to confirm, the merchant should not change when receipt is changed

[mollfpr]

to confirm, the merchant should not change when receipt is changed

@mountiny Does this mean the SmartScanning will work fine with merchant field fill?

[tienifr]

to confirm, the merchant should not change when receipt is changed

Just want to confirm your mean.

• The merchant is initially set to Request
• Users upload the receipt, that means they want to change the merchant to what SmartScanning returns -> We should reset merchant in this case
• They change the merchant name after uploading receipt, that means they don't want to lean on SmartScanning -> So when they edit the receipt, we should not reset the merchant

Please correct me if I wrong something. Thanks @mountiny cc @mollfpr

[mountiny]

We are working on making the merchant field required for group policies/ requests in workspace #32486 so it would not be set to Request thats

cc @trjExpensify to help with the expected behaviour here.

If the merchant is passed we would not smartscan

If the user inputs some merchant, then we assume they dont want smartscan, if they upload different receipt at the confirmation page though, it should not reset automatically the merchant previously inserted. If the receipt is different and the merchant should be too, they can update it again.

[mollfpr]

Not overdue

[melvin-bot]

@peterdbarkerUK @mollfpr this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

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

[melvin-bot]

@peterdbarkerUK, @mollfpr Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@peterdbarkerUK @mollfpr this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[melvin-bot]

@peterdbarkerUK, @mollfpr 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[mollfpr]

@tienifr Do you need to update your proposal based on the #32123 (comment)?

[FitseTLT]

@mollfpr It is not reproducible anymore after the recent money request refactor.

[melvin-bot]

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

[tienifr]

cc @trjExpensify to help with the expected behaviour here.

@mollfpr I think we're waiting for @trjExpensify's response

[mollfpr]

Thanks @FitseTLT. I just tested on the latest main, and the issue is fixed.

Screen.Recording.2023-12-20.at.19.06.57.mp4

[trjExpensify]

Same, I can't reproduce this anymore either.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[mollfpr]

@peterdbarkerUK We can close this issue.

[melvin-bot]

@peterdbarkerUK @mollfpr this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

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

[mountiny]

Sorry for this but happy this got resolved!