App: [HOLD for payment 2024-05-03] [$500] Unable to mark system message unread in one transaction view

Hello, I am Arek from Callstack - expert contributor group. I’d like to work on this issue.

Proposal

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

Unable to mark system message as unread in one transaction view.

What is the root cause of that problem?

When the first IOU is created, of a group of IOUs shown in a report preview, the transaction thread report for that IOU is obscured. Rather than viewing the actual transaction report, the user views the IOU report. When there is more than one IOU in the IOU report the user chooses which IOU to view. After clicking on the desired IOU the user is able to view the transaction report for that IOU. In this case there is only one IOU in the IOU report. What the user sees looks like a transaction report for the one and only IOU, but the user is actually viewing the IOU report itself. The transaction report is obscured.

In this situation any comments the user makes are attached to the IOU report, not the transaction report. When the user changes the category, the system generates a message and that message is attached to the transaction report, rather than to the IOU report.

When the user marks the system message as unread the transaction report is marked as unread, but that report is obscured. The IOU report is not marked as unread.

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

In this situation it is not a good idea to attach any comments, made by the user or by the system, to the IOU report since from the users perspective the comments are expected to be attached to the transaction report since what the user sees looks exactly like a transaction report (a report of the details of the transaction).

If the user makes a comment or changes the category, change the view to match that when there is more than one IOU in the IOU report. This will solve the problem.

Another approach is to only make that change when the user changes the category, and to let everyone know about the other issue.

If we do change the view to match that when there is more than one IOU in the IOU report then the user would need to click twice to get to a transaction view, which could be irritating to the user. To avoid irritation, check to see if there is only one IOU and if so simply navigate directly to the actual transaction report, skipping the IOU report. By doing this the user will not notice any difference from the current behavior, and both of the above problems are solved.

ReportScreen already checks to see if the current report is an IOU report with exactly one IOU report action, by calling ReportActionsUtils.getOneTransactionThreadReportID here: https://github.com/Expensify/App/blob/9b839f4f18d724dba1ed17ed5967f7e033781428/src/pages/home/ReportScreen.tsx#L339-L342

When there is exactly one IOU report action, transactionThreadReportID will not be null and we can navigate to that report. If we do this, we will also want to make sure that the user can easily navigate back directly to the main chat from the transaction report.

To facilitate navigating back we can use CONST.NAVIGATION.TYPE.FORCED_UP to navigate to the transaction report.

That will help, but there is another issue to consider. In the money request header of the transaction report there will be a link to the skipped IOU report (see onPress of the ParentNavigationSubtitle shown below). If the user clicks on that link there will be no response, since navigating to the IOU report results in automatically navigating to back to the transaction report.

https://github.com/Expensify/App/blob/9a6cafcabfcbaa4f81fe57d0fecbeab682b8309a/src/components/ParentNavigationSubtitle.tsx#L35-L44

One quick solution to this particular problem is to change the behavior of clicking on the subtitle link to match the behavior of the back button, which is to call Navigation.goBack() (without any parameters). If we do that, and then open the transaction report from a deep-link, and then click on the subtitle link, there will be no response because it is not possible to navigate back.

Another possible solution is for ParentNavigationSubtitle to check to see if the parent report is an IOU report with exactly one IOU, and if so set the link to navigate back to the parent of the parent report instead.

Since it was reopened, I’ll reference this comment as the relevant issue description.

@paultsimura Sorry for the delay. I’m currently highly focused on other stuff. Could you please assign me?

I was able to reproduce it on staging yesterday in the morning. Seems like yesterday’s release fixed the issue. Could we please have QA retest this one @amyevans?

I’ve noticed the scroll-down (and indicator display) works fine with reportActions that occur on the report (e.g. commenting) but not with actions that occur on the expense (updating the merchant)

Okay nice, this made it a lot easier to test locally than fumbling around with SmartScan. I was able to reproduce by just creating an expense and updating a field on it, as you said.

I retested following the merge of the fix you mentioned (https://github.com/Expensify/App/pull/39474), unfortunately the issue is still reproducible:

https://github.com/Expensify/App/assets/7277067/9a6fd5c4-8165-4592-9ec9-938937276f15

• Any expense level report action cannot be marked unread
• If the latest report action on the report is from the expense level, the New messages button does not scroll you down

I’ll look into a fix but this wasn’t accounted for in the initial PR we can maybe remove the blocker label for the moment since it’s an easy work around for a one-expense report. What do you think?

@NikkiWines that sounds good to me, thanks for clarifying things here. I’ll go ahead and remove the blocker label since it looks like this is going to be resolved soon.