[$500] In the archived room, the user has access to the IOU editing panel in the RHP

[m-natarajan]

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.40-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. Open https://staging.new.expensify.com/
2. Log in under your HT account
3. Create WS
4. Send the IOU to the WS room
5. Delete the created WS
6. Navigate to the archived WS room with the sent IOU
7. Open the details of the IOU
8. Try to edit any IOU details

Expected Result:

If the IOU is in the archive room, the user should not be able to edit details. The IOU should look like a paid IOU but without the green check mark.

Actual Result:

In the archived room, the user has access to the IOU editing panel in the RHP.

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

Bug6377196_1707769765126.Recording__1329.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010ac3ccf6d4ee887b
• Upwork Job ID: 1757145612587610112
• Last Price Increase: 2024-03-11

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~010ac3ccf6d4ee887b

[melvin-bot]

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

[melvin-bot]

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

[m-natarajan]

We (Applause) think this might be related to #vip-bills
cc @davidcardoza

[Tony-MK]

Proposal

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

What is the root cause of that problem?

The root cause is that IOU reports are not getting archived.

In the filter below, located in the deleteWorkspace function, IOU report is not being considered.

App/src/libs/actions/Policy.ts

Line 306 in 89df622

(report) => report?.policyID === policyID && (ReportUtils.isChatRoom(report) || ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isTaskReport(report)),

Also, the canEditMoneyRequest and canEditFieldOfMoneyRequest functions do not check if the report has been archived.

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

Firstly, add the ReportUtils.isIOURequest and the ReportUtils.isMoneyRequest function to the filter in the deleteWorkspace function

App/src/libs/actions/Policy.ts

Line 306 in 89df622

(report) => report?.policyID === policyID && (ReportUtils.isChatRoom(report) || ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isTaskReport(report)),

(report) => report?.policyID === policyID && (ReportUtils.isChatRoom(report) ||
ReportUtils.isPolicyExpenseChat(report) ||
ReportUtils.isTaskReport(report) ||
ReportUtils.isIOUReport(report)) || 
ReportUtils.isMoneyRequest(report))

Secondly, we should check if the report has been archived before the line below to improve the canEditMoneyRequest function.

App/src/libs/ReportUtils.ts

Line 2060 in 59559c4

if (isIOUReport(moneyRequestReport)) {

What alternative solutions did you explore? (Optional)

If we to only affect the amount field, we can use the isArchivedRoom function in the canEditFieldOfMoneyRequest function.

App/src/libs/ReportUtils.ts

Lines 2108 to 2110 in 59559c4

	if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.AMOUNT || fieldToEdit === CONST.EDIT_REQUEST_FIELD.CURRENCY) {
	if (TransactionUtils.isCardTransaction(transaction)) {
	return false;

[situchan]

reviewing proposal

[jacobkim9881]

Should this cared as an issue? Since the chat room is archived, a user can't do anything without paid button and can see it is archived as a room name.

[melvin-bot]

@stephanieelliott, @situchan Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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

[situchan]

IOU reports won't be archived after deleting workspace

[Tony-MK]

Hi @situchan, thanks for reviewing my proposal.

After some investigation, I have a quick question.

I think the IOU reports do get archived because when trying to edit the amount field, the following response is received:

Therefore, is it reasonable to check if the workspace is archived and deny the user the ability to edit the amount field?

The other IOU fields show the NotFoundPage component.

Should we mimic this behavior instead?

Thank you.

[jacobkim9881]

@Tony-MK question seems reasonable. It seems editing amount returns error and editing other field is blocked too? These are different to Actual Result above.

[situchan]

@Tony-MK please test on latest version. IOU reports don't get archived after deleting workspace

[Tony-MK]

@situchan Thanks for help.

I updated my proposal based on the comment ⬆️.

Could you review it?

However, I also noticed that the behavior I mentioned in #36371 (comment) also occurs.

Thank you

[brandonhenry]

Proposal

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

In the archived room, users currently have the ability to access and edit the IOU details panel in the RHP. This behavior is inconsistent with the expected functionality, as editing IOUs in an archived room should not be possible.

What is the root cause of that problem?

The root cause of this issue is that the MoneyRequestView component does not perform a check to determine if the room is archived before enabling the edit functionality for the IOU details. This oversight allows users to access and modify IOU details in archived rooms, which should be a read-only scenario.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 125 in 5eed632

const canEdit = ReportUtils.canEditMoneyRequest(parentReportAction);

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

To address this issue, we should update the logic within the MoneyRequestView component to include a check for whether the room is archived. This can be achieved by utilizing the ReportUtils.isArchivedRoom method to determine the archived status of the room. If the room is archived, the editing capabilities for the IOU should be disabled. Specifically, we should adjust the conditions for enabling edit capabilities (canEdit, canEditAmount, canEditMerchant, canEditDate, canEditReceipt, canEditDistance) by adding a check to ensure that the room is not archived. Here's the suggested update:

const isArchived = ReportUtils.isArchivedRoom(moneyRequestReport);
// Used for non-restricted fields such as: description, category, tag, billable, etc.
const canEdit = ReportUtils.canEditMoneyRequest(parentReportAction) && !isArchived;
const canEditAmount = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.AMOUNT) && !isArchived;
const canEditMerchant = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.MERCHANT) && !isArchived;
const canEditDate = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.DATE) && !isArchived;
const canEditReceipt = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.RECEIPT) && !isArchived;
const canEditDistance = ReportUtils.canEditFieldOfMoneyRequest(parentReportAction, CONST.EDIT_REQUEST_FIELD.DISTANCE) && !isArchived;

By incorporating this change, we ensure that editing IOU details is disabled in archived rooms, aligning the application's behavior with the expected result. This solution directly addresses the root cause by adding the necessary condition to check the archived status of the room before enabling edit functionalities.

[melvin-bot]

@stephanieelliott @situchan 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!

[situchan]

Not sure if something changed recently. Now all money request reports are archived after deleting workspace.
This should not happen as per #35174 (comment)
@cristipaval can you please confirm?

[Tony-MK]

Not sure if something changed recently. Now, all money request reports are archived after deleting workspace.

Hi @situchan, the backend archives the report, not the front end, because while deleting the workspace offline, the IOU report is not archived until the user goes online.

The server side changes discussed in this #29049 (comment) and decided in its #29049 (comment) were made to archive task threads also archived IOUs report.

The screenshot below shows the IOU report, which has a key of report_7758574277954490 from the part of the command=DeleteWorkspace API response.

Note the statusNum and stateNum are set to 2 to mean it's closed.

[melvin-bot]

@stephanieelliott @situchan 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]

@stephanieelliott, @situchan Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[situchan]

Waiting for confirmation here

[cristipaval]

I asked internally here

[cristipaval]

Assigned myself for now until the internal discussion ends

[cristipaval]

Not sure if something changed recently. Now all money request reports are archived after deleting workspace. This should not happen as per #35174 (comment) @cristipaval can you please confirm?

Yes, the money requests are now archived and we might change this soon. But until we change this, I think we should proceed with the fix for the current issue and block the editing.

[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]

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

[stephanieelliott]

Ok so based on the discussion it sounds like we should update the front end to match the future back end implementation plans and not allow editing on an archived transaction. Now that that's clarified, I think we can proceed with the existing proposals, right @situchan? Are there any proposals here that will work?

[stephanieelliott]

Another internal conversation about this here: https://expensify.slack.com/archives/C036QM0SLJK/p1710283476740279

[cristipaval]

I'm closing this one based on where we landed in the conversation linked by @stephanieelliott above

[Tony-MK]

I'm closing this one based on where we landed in the conversation linked by @stephanieelliott above

I don't know what occurred in the slack conversation but unpaid money requests get archived only backend.

Since the front end doesn't get archive money requests offline, shouldn't we address this to adhere to our offline patterns by optimistically archiving the report?

Stephanie mentioned it in this #36371 (comment) and I am curious. 🤔

Thanks.