[HOLD for payment 2024-05-01] [$500] Workspace – “Submitted $amount” system message appears for a moment when Employee submit IOU

[lanitochka17]

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.54-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4434476
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in as Employee of a Collect WS
3. Open WS chat and request a money
4. Open IOU and press Submit button in the header

Expected Result:

“You submitted this report to Admin (email)” system message appears when Employee submit IOU

Actual Result:

“Submitted $amount” system message appears for a moment when Employee submit IOU and then appears “You submitted this report to Admin (email)”

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

Bug6419091_1710846730210.Submitted__amount.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01304a705cb67bed22
• Upwork Job ID: 1770177446924410880
• Last Price Increase: 2024-03-19
• Automatic offers:
• situchan | Reviewer | 0
• FitseTLT | Contributor | 0

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

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

[lanitochka17]

@garrettmknight FYI 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

[garrettmknight]

Confirmed the bug - I think it fits in #wave-collect.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01304a705cb67bed22

[melvin-bot]

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

[FitseTLT]

Proposal

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

Workspace – “Submitted $amount” system message appears for a moment when Employee submit IOU

What is the root cause of that problem?

The optimistic submited report action contains message with only one fragment of submitted amount

App/src/libs/actions/IOU.ts

Lines 3893 to 3894 in 0d700c3

	const optimisticSubmittedReportAction = ReportUtils.buildOptimisticSubmittedReportAction(expenseReport?.total ?? 0, expenseReport.currency ?? '', expenseReport.reportID);
	const parentReport = ReportUtils.getReport(expenseReport.parentReportID);

App/src/libs/ReportUtils.ts

Lines 3175 to 3176 in 0d700c3

	iouMessage = `submitted ${amount}`;
	break;

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

The optimistic submitted report action should have all the message fragments same as what the BE returns
like

[
  {
    "type": "TEXT",
    "style": "strong",
    "text": "You"
  },
  {
    "type": "TEXT",
    "style": "normal",
    "text": " submitted this report"
  },
  {
    "type": "TEXT",
    "style": "normal",
    "text": " to "
  },
  {
    "type": "TEXT",
    "style": "strong",
    "text": "F A T ([email protected])"
  }
]

Submitted to account can be taken from policy.ownerAccountID so We can update buildOptimisticSubmittedReportAction to

  function buildOptimisticSubmittedReportAction(amount: number, currency: string, expenseReportID: string, policy): OptimisticSubmittedReportAction {
    const originalMessage = {
        amount,
        currency,
        expenseReportID,
    };
    const ownerPersonalDetails = getPersonalDetailsForAccountID(policy.ownerAccountID);

    return {
        actionName: CONST.REPORT.ACTIONS.TYPE.SUBMITTED,
        actorAccountID: currentUserAccountID,
        automatic: false,
        avatar: getCurrentUserAvatarOrDefault(),
        isAttachment: false,
        originalMessage,
        message: [
            {
                type: CONST.REPORT.MESSAGE.TYPE.TEXT,
                style: 'strong',
                text: 'You',
            },
            {
                type: CONST.REPORT.MESSAGE.TYPE.TEXT,
                style: 'normal',
                text: ' submitted this report',
            },
            {
                type: CONST.REPORT.MESSAGE.TYPE.TEXT,
                style: 'normal',
                text: ' to ',
            },
            {
                type: CONST.REPORT.MESSAGE.TYPE.TEXT,
                style: 'strong',
                text: `${ownerPersonalDetails.displayName} (${ownerPersonalDetails.login})`,
            },
        ],

We can move this change to getIOUReportActionMessage (only updating SUBMITTED case)
And moreover We can think of more complex logic especially to determine the first and last fragments, especially the last because the way display name and login are displayed depend on their existence.

What alternative solutions did you explore? (Optional)

[allgandalf]

Proposal

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

“Submitted $amount” system message appears for a moment when Employee submit IOU

What is the root cause of that problem?

Currently we display submitted and the amount using getIOUReportActionMessage :

App/src/libs/ReportUtils.ts

Lines 3174 to 3176 in ca0cf24

	case CONST.REPORT.ACTIONS.TYPE.SUBMITTED:
	iouMessage = `submitted ${amount}`;
	break;

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

Remove the following condition, as we get the data as system message

App/src/libs/ReportUtils.ts

Lines 3174 to 3176 in ca0cf24

	case CONST.REPORT.ACTIONS.TYPE.SUBMITTED:
	iouMessage = `submitted ${amount}`;
	break;

What alternative solutions did you explore? (Optional)

N/A

[iammudassirali]

Proposal

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

The issue involves a momentary display of the "Submitted $amount" system message when an Employee submits an IOU in the Expensify workspace. This message is unexpected and causes confusion among users.

What is the root cause of that problem?

The root cause of this problem appears to be a timing issue in the system message display mechanism. It seems that the "Submitted $amount" message is briefly shown before being replaced by the correct "You submitted this report to Admin (email)" message.

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

To solve this issue, we need to adjust the timing or sequence of events related to the display of system messages when an IOU is submitted. This may involve modifying the backend logic or frontend rendering to ensure that the correct message is displayed immediately without any intermediate messages.

What alternative solutions did you explore? (Optional)

An alternative solution could involve implementing a more robust message handling mechanism that prevents the display of any interim messages during the submission process. Additionally, we could explore optimizing the system response time to minimize the delay in displaying the correct message.

By addressing the timing issue and ensuring consistent messaging behavior, we can enhance the user experience and eliminate confusion during IOU submission in the Expensify workspace.

Please let me know if you need further clarification or assistance with implementing this solution.

Best regards,
Mudassir Ali.

[garrettmknight]

@situchan can you take a look at these proposals when you get a chance?

[situchan]

reviewing

[situchan]

@FitseTLT's proposal looks good to me.
We need to make sure that optimistic message and server message are exactly the same, not only text but also style.
🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @pecanoro, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[pecanoro]

Sounds good, assigning @FitseTLT to the issue

[melvin-bot]

📣 @situchan 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @FitseTLT 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[FitseTLT]

PR will be up in 3 days

[melvin-bot]

@garrettmknight, @pecanoro, @hungvu193, @FitseTLT Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[garrettmknight]

Still working through the PR

[melvin-bot]

@garrettmknight, @pecanoro, @hungvu193, @FitseTLT Whoops! This issue is 2 days overdue. Let's get this updated quick!

[pecanoro]

Hmm,, it seems the automation didn't get triggered to update the title and payment

[garrettmknight]

@hungvu193 had to send a new offer: https://www.upwork.com/nx/wm/offer/102083093

[hungvu193]

@hungvu193 had to send a new offer: https://www.upwork.com/nx/wm/offer/102083093

Accepted. Thank you!

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[garrettmknight]

Payment summary:

• Contributor: @FitseTLT $500 paid via Upwork
• Reviewer: @hungvu193 $500 paid via Upwork

[garrettmknight]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• @hungvu193 The PR that introduced the bug has been identified. Link to the PR:
• @hungvu193 The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• @hungvu193 A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• @hungvu193 Determine if we should create a regression test for this bug.
• @hungvu193 If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• @garrettmknight Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[garrettmknight]

@hungvu193 please complete the checklist when you get a chance.

[hungvu193]

• The PR that introduced the bug has been identified. Link to the PR: [NoQA] Feat: Add submit action #28947
• The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: https://github.com/Expensify/App/pull/28947/files#r1586975839
• A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• Determine if we should create a regression test for this bug: No

This is a minor bug, so I don't think we need a regression test for it. Instead, we need to ensure that the optimistic data from the client matches what is returned from the server to avoid this kind of bug in the future.

[melvin-bot]

@garrettmknight, @pecanoro, @hungvu193, @FitseTLT Whoops! This issue is 2 days overdue. Let's get this updated quick!

[pecanoro]

@garrettmknight All yours!