[HOLD #299672] [$1000] Report Recipient Local Time does not appear in sender

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open 2 accounts on 2 browsers and 2 account not has chat before
2. A open chat with B and send any message
3. From B, the appearance of Recipient Local Time is observed but From A does not appear

Expected Result:

Recipient Local Time Must appear in both user A and B

Actual Result:

Recipient Local Time appears only in recipients.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.47-3
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
Notes/Photos/Videos: Any additional supporting documentation

Screen.Recording.2023-07-28.at.00.43.26.mov

Recording.1398.mp4

Expensify/Expensify Issue URL:
Issue reported by: @namhihi237
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690480211518189

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0109b85d32df0f6e6f
• Upwork Job ID: 1686039411845201920
• Last Price Increase: 2023-07-31

[melvin-bot]

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

[dummy-1111]

The backend doesn't send full user info

[namhihi237]

NOTE: even after user B sent back the message there is no recipient time

Screen.Recording.2023-07-29.at.10.20.50.mov

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0109b85d32df0f6e6f

[melvin-bot]

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

[melvin-bot]

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

[CortneyOfstad]

@ArekChr Couple of comments above for your review 👍 TIA!

[jeet-dhandha]

Proposal

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

• User is unable to see the Recipient Local Time.

What is the root cause of that problem?

• Recipient Local Time is not being displayed as below condition is getting false:
  

  App/src/libs/ReportUtils.js

  Line 750 in b50948a

  const isReportParticipantValidated = lodashGet(reportRecipient, 'validated', false);

• which is an expected behavior as we don't want to show the local time if the Recipient has not sent any message to the User.

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

• Here we need to decide on whether we want to show the local time or not if the Recipient has not sent any message to the User. Based on that above issue should be resolved.

What alternative solutions did you explore? (Optional)

• N/A

[ArekChr]

@CortneyOfstad I think this might be a backend issue

[CortneyOfstad]

Okay, going to get engineering eyes on this, just in case. I'm heading OoO until 8/14 so reapply the BZ label as well to keep eyes on this while I'm out 👍

[melvin-bot]

Triggered auto assignment to @jliexpensify (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 @PauloGasparSv (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[PauloGasparSv]

Had no time to check the updates here but thanks in advance! Will try to pick this back up tomorrow, focused on WAQ and W/N issues Today

Hey same here so no updates! I made progress on the issues I was working on so I'll be able to return to this ASAP, sorry for the delay!

[PauloGasparSv]

Thks for the help, I investigated this a bit further today.
I still think we'll need to fix this on the API for this to work!

Btw, Re-opening the report (triggering a call to OpenReport) after users are known make the recipient time appear.

I'll have to start a discussion on slack about this to get some help and also discuss wether or not this is worth fixing/changing!

[PauloGasparSv]

Discussed this with the team and since we may implement a new NVP for checking known users I'm putting this on HOLD for https://github.com/Expensify/Expensify/issues/299672!

[PauloGasparSv]

Changing this to weekly, the issue we are holding had some updates but is still in progress.

[CortneyOfstad]

Can take this back now that I'm back in office — thanks for holding down the fort @jliexpensify!

[huzaifa-99]

Proposal

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

We want the local time to correctly show local time on both the sender and receiver side in threads

What is the root cause of that problem?

We handle participant ids differently in the case of task and money request reports. For these types of reports, we only include the assignee/requestee id in the participant ids, the assigner/requester id gets stored in the onwerAccountID key of the same report object.
For normal threads, we don't set the participant ids until the receiver responds and we fetch the report data again.

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

We can update the way we calculate report participant's here and here to include cases for task/money/simple-thread report types.
For task and money request reports, the report.participantAccountIDs array would have the id of the assignee/requestee on both the assigner/requester and assignee/requestee side, we already filter the current user account id, so we can add the concat the report owner id with participants ids and then filter, something like this

// pseudocode
const initialIDs = lodashGet(report, 'participantAccountIDs', []);
const updatedIDs = (isTaskReport(report) || isMoneyRequestReport(report)) ? _.union(initialIDs, [report.ownerAccountID]) : initialIDs
const reportParticipants = _.without(updatedIDs, currentUserAccountID)

and in the case of simple threads, we can get the parent report participants (we could also update the participant list upon thread creation)

// pseudocode
report = isThread(report) && !(isTaskReport(report) || isMoneyRequestReport(report)) ? lodashGet(allReports, [`${ONYXKEYS.COLLECTION.REPORT}${report.parentReportID}`]) : report

and abstract all of this logic into ReportUtils.

// pseudocode
function getReportParticipantIDs(report, currentUserAccountID){
    const updatedReport = isThread(report) && !(isTaskReport(report) || isMoneyRequestReport(report)) ? lodashGet(allReports, [`${ONYXKEYS.COLLECTION.REPORT}${report.parentReportID}`]) : report
    const initialIDs = lodashGet(updatedReport, 'participantAccountIDs', []);
    const updatedIDs = (isTaskReport(updatedReport) || isMoneyRequestReport(updatedReport)) ? _.union(initialIDs, [updatedReport.ownerAccountID]) : initialIDs
    return _.without(updatedIDs, currentUserAccountID);
}

I am not sure if we want to show the local time in case of workspace threads, if we don't we can add !isWorkspaceThread(report) in the updatedReport condition

What alternative solutions did you explore? (Optional)

We could also update how we set the participant ids for money/task and simple threads, but this would require some decent refactoring.

[PauloGasparSv]

I'm starting to get confused with one thing, more than 1 proposal sent here mentioned IOU's and Tasks's specifically but I'm pretty sure this is happening for normal 1:1 chats as long as the user's are unknown to each other no?

That's why I think this fix should be done in the API and should be applied to all Chat Types.

Please LMK if I'm not understanding something here : )

[huzaifa-99]

@PauloGasparSv I just came from this slack bug report (but it was a dupe)

And these are 2 separate issues actually

• This one happens with normal 1:1 chats (new chats), and seems more on the API side
• While [HOLD for payment 2023-09-29] [$1000] Time of User A doesn't appear for User B in IOU or Task room. #24228 was for IOUs/Task, and is a frontend issue but it got closed as a dupe of this issue.

I think we should reopen #24228.

[PauloGasparSv]

Thks so much for explaining @huzaifa-99 that makes total sense

I think we should reopen #24228

They may be separate issues but I also think that fixing OpenReport might fix both problems.

I think it's ok to keep that issue close for now and re-open it once this one is off HOLD in case the problem persists if that's ok : )

[CortneyOfstad]

Thanks @PauloGasparSv!

[CortneyOfstad]

Reassigning engineering in replacement of Paulo 👍

[melvin-bot]

Triggered auto assignment to @mountiny (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[mountiny]

Btw, Re-opening the report (triggering a call to OpenReport) after users are known make the recipient time

I think this is actually the case, its expected that you dont see the timezone of unknown user, then when they message back, iI think its fine that we only show the time when you open the report again.

@CortneyOfstad @ArekChr I would close this issue as actually not a bug we need to fix. The time is correctly updated after another OpenReport. Let me know if you disagree or I misunderstood this

[huzaifa-99]

@mountiny #24228 was closed as a dupe of this issue but it looks like a different one since the users are known there. I left a comment about this here.

The current issue happens with normal 1:1 chats (new chats), and seems more on the API side
While #24228 was for IOUs/Task, and is a frontend issue but it got closed as a dupe of this issue.

Can you please check if we should reopen #24228? Thank you!