[$500] IOU - "Unsubscribe from thread" button is visible on the hover menu

[kavimuru]

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.4.24.7
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. Create a workspace
2. Create a scan IOU with a PDF in the workspace chat (make sure to keep hovering over the IOU on Windows)

Expected Result:

The button shouldn't disappear.

Actual Result:

"Unsubscribe from thread" button is visible for a short time on the hover menu.

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: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6339779_1705039568974.bandicam_2024-01-12_06-59-14-888.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0117b089c8644a20b4
• Upwork Job ID: 1745750063528005632
• Last Price Increase: 2024-01-12

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0117b089c8644a20b4

[melvin-bot]

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

[DylanDylann]

Proposal

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

"Unsubscribe from thread" button is visible for a short time on the hover menu.

What is the root cause of that problem?

App/src/pages/home/report/ContextMenu/ContextMenuActions.js

Line 206 in b6a18b1

const subscribed = childReportNotificationPreference !== 'hidden';

In here because we don't set childReportNotificationPreference in reportAction of request money message, childReportNotificationPreference is empty string then we check isActionCreator

App/src/pages/home/report/ContextMenu/ContextMenuActions.js

Lines 201 to 202 in b6a18b1

	const isActionCreator = ReportUtils.isActionCreator(reportAction);
	childReportNotificationPreference = isActionCreator ? CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS : CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN;

so subscribed is true and we display unsubcribe button on the context menu

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

Note that: This bug only be happened at a moment because the API return childReportNotificationPreference: 'hidden' in reportAction of request money message

We should set childReportNotificationPreferenc === 'hidden' in optimistic data of request money message

App/src/libs/ReportUtils.ts

Line 2899 in b6a18b1

return {

We should add

childReportNotificationPreference: 'hidden'

as the value is returned from BE

What alternative solutions did you explore? (Optional)

NA

[bernhardoj]

Proposal

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

The unsubscribe option menu shows for a brief moment on a scanning request.

What is the root cause of that problem?

One of the conditions the unsubs option will show is that the childReportNotificationPreference is not hidden. When we create a scan request, the childReportNotificationPreference is empty.

App/src/pages/home/report/ContextMenu/ContextMenuActions.js

Lines 199 to 213 in b6a18b1

	let childReportNotificationPreference = lodashGet(reportAction, 'childReportNotificationPreference', '');
	if (!childReportNotificationPreference) {
	const isActionCreator = ReportUtils.isActionCreator(reportAction);
	childReportNotificationPreference = isActionCreator ? CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS : CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN;
	}
	const isDeletedAction = ReportActionsUtils.isDeletedAction(reportAction);
	const shouldDisplayThreadReplies = ReportUtils.shouldDisplayThreadReplies(reportAction, reportID);
	const subscribed = childReportNotificationPreference !== 'hidden';
	if (type !== CONST.CONTEXT_MENU_TYPES.REPORT_ACTION) {
	return false;
	}
	const isCommentAction = reportAction.actionName === CONST.REPORT.ACTIONS.TYPE.ADDCOMMENT && !ReportUtils.isThreadFirstChat(reportAction, reportID);
	const isReportPreviewAction = reportAction.actionName === CONST.REPORT.ACTIONS.TYPE.REPORTPREVIEW;
	const isIOUAction = reportAction.actionName === CONST.REPORT.ACTIONS.TYPE.IOU && !ReportActionsUtils.isSplitBillAction(reportAction);
	return subscribed && (isCommentAction || isReportPreviewAction || isIOUAction) && (!isDeletedAction || shouldDisplayThreadReplies);

Because it's empty, based on the logic above, the value will default to ALWAYS because we are the creator. Then, later we will get a HIDDEN value from the server, so the button hides, but the subscribe option never shows because we hide it if it's a whisper.

App/src/pages/home/report/ContextMenu/ContextMenuActions.js

Lines 170 to 171 in b6a18b1

	const isWhisperAction = ReportActionsUtils.isWhisperAction(reportAction);
	return !subscribed && !isWhisperAction && (isCommentAction || isReportPreviewAction || isIOUAction) && (!isDeletedAction || shouldDisplayThreadReplies);

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

We can hide the unsubscribe option too if it's a whisper.

we can optionally set the notification preference to hidden optimistically ONLY when the request is going to be scanned by checking the length of the whisperedToAccountIDs in buildOptimisticIOUReportAction

[AliKhokhar123]

Contributor details
Your Expensify account email: alikhokhar01233210@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~015c32305f13acc7f8

Problem Statement:
The "Unsubscribe from thread" button is briefly visible on the hover menu, causing a momentary glitch.

Root Cause Analysis:
Upon reviewing the provided information, it appears that the issue lies within the handling of childReportNotificationPreference in the ContextMenuActions.js file. Specifically, when creating a scan request, childReportNotificationPreference is initially empty, and later, a value of 'hidden' is returned from the server. However, due to the logic in place, the value defaults to 'ALWAYS' before being updated to 'HIDDEN', causing the button to briefly appear.

Solution Approach:
To address this issue, I propose the following changes:

Explicitly Set childReportNotificationPreference:
In cases where the API returns childReportNotificationPreference: 'hidden' for a scan request, we should explicitly set this value in the ContextMenuActions.js file. This ensures that the correct notification preference is established upfront, preventing the momentary display of the "Unsubscribe from thread" button.

javascript
Copy code
// Add this line where appropriate based on the logic flow
childReportNotificationPreference = 'hidden';
Optional Setting for Whisper Cases:
Considering the nature of the whisper scenario, we can hide the "Unsubscribe from thread" button if it's a whisper. This adjustment ensures that the button is not visible when it shouldn't be, providing a more consistent user experience.

javascript
Copy code
// Update the existing condition to include the check for whisper
return subscribed && (isCommentAction || isReportPreviewAction || isIOUAction) && (!isDeletedAction || shouldDisplayThreadReplies) && !isWhisper;
Optimistic Setting for Scanned Requests:
Optionally, we can set the notification preference to 'hidden' optimistically when the request is going to be scanned. This can be achieved by checking the length of the whisperedToAccountIDs in the buildOptimisticIOUReportAction function.

javascript
Copy code
// Add this check in buildOptimisticIOUReportAction
if (whisperedToAccountIDs.length > 0) {
reportAction.childReportNotificationPreference = 'hidden';
}

Conclusion:
These proposed changes aim to resolve the issue of the momentary visibility of the "Unsubscribe from thread" button by ensuring proper handling of childReportNotificationPreference in relevant scenarios. I am committed to implementing these changes once officially onboarded and given access to the codebase.

I look forward to your feedback and the opportunity to contribute to enhancing the stability and usability of the Expensify system.

Best regards,
Ali Ahmed

[melvin-bot]

📣 @AliKhokhar123! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[s77rt]

@DylanDylann Thanks for the proposal. Your RCA is about right. However when the server response is received I expected the subscribe button to appear. The fact that it didn't means we have some other inconsistency to deal with (not a blocker). Setting the childReportNotificationPreference in the optimistic data is not a wrong approach but I don't think it's necessary, we don't seem to be setting this field anywhere so let's keep it that way for simplicity.

[s77rt]

@bernhardoj Thanks for the proposal. Your RCA is correct. Hiding the unsubscribe option for whisper actions seems to be the most straightforward solution here. Let's go with that.

🎀 👀 🎀 C+ reviewed
Link to proposal

cc @srikarparsi

[melvin-bot]

Current assignee @puneetlath is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[s77rt]

@AliKhokhar123 Thanks for the proposal. Unfortunately it's a dupe.

[s77rt]

@puneetlath While at it, can you check those two BE bugs (also related to this issue):

Bug 1:

1. Create IOU request (manual)
2. The childReportNotificationPreference should be always

Bug 2

1. Create IOU request (scan)
2. The childReportNotificationPreference should be always even if it's scanning. I don't see why it's being returned as hidden

Technically the BE fix should also fix this issue. But for consistency I think we should still apply the FE fix (disable unsubscribe option for whisper actions)

Screen.Recording.2024-01-13.at.2.44.54.PM.mov

[s77rt]

Not overdue. @puneetlath ^

[srikarparsi]

Hey, coming from this issue where we removed the ability to subscribe and reply in thread to whisper messages. The rationale for keeping the unsubscribe from thread option is that it would make it easier to remove these threads from a users LHN but if we remove the unsubscribe from thread option, they would still be able to remove it by clicking into the thread. Also, I left a comment here with the reasoning behind removing subscribe and reply in thread from whisper messages.

[s77rt]

Not overdue. @puneetlath ^

[s77rt]

@puneetlath ^

[puneetlath]

@srikarparsi are you saying that the current behavior is the right behavior and we should close this issue?

[srikarparsi]

Sorry, I think that this issue is a bug. I just think that the solution to this is to remove the unsubscribe from thread in the same way that we removed the subscribe and reply in thread options for whisper options.

I previously wanted to keep the unsubscribe from thread option so that it would make it easier to remove these threads from a users LHN but since this is causing bugs I don't think it's too needed. Users can still remove these threads by clicking into them and leaving from the top right of the header.

[s77rt]

@puneetlath Did you get a chance to check #34428 (comment)?

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[s77rt]

@puneetlath ^

[melvin-bot]

@puneetlath @s77rt 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!

[s77rt]

@puneetlath When you get a chance please check #34428 (comment)

Also cc @rlinoz as I think you worked on notification preferences

[rlinoz]

I think we started returning hidden so it doesn't show up in the LHN, but I am not sure if this is the same thing.

cc: @srikarparsi @marcaaron

[s77rt]

Not overdue. ^

[srikarparsi]

Hey, we actually removed the leave thread/unsubscribe from thread option everywhere so I don't think this issue will be there anymore?

[melvin-bot]

@puneetlath @s77rt 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 @s77rt is eligible for the Internal assigner, not assigning anyone new.

[s77rt]

@srikarparsi Correct! This is no longer reproducible

[puneetlath]

Ah cool, I'll go ahead and close this out then. Thanks y'all.