[Hold for payment 2024-03-06] [$500] Workspace-The archived task report is no longer archived after reopening the report.

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Launch app
2. Tap announce room
3. Tap plus icon
4. Select assign task
5. Enter title "Ree task" and tap next
6. Tap confirm task
7. Navigate back to LHN
8. Tap profile
9. Tap Workspaces
10. Select the Workspace(in whose announce room task is created)
11. Tap on 3dots on top and delete the workspace
12. Navigate to LHN and note the created task( " Ree Task") is archived
13. Tap on archived Workspace and confirm Workspace is archived
14. Open the archived announce room
15. Tap on the task and note the task report header
16. Tap back and tick the task
17. Tap on the task again and note the task report header

Expected Result:

In archived WS-announce room, user must not be able to tick the task and interact.
The archived task report must remain archived after reopening the report also.

Actual Result:

In archived WS-announce room, user able to tick the task and interact.
The archived task report is no longer archived after reopening the report.

Workaround:

Unknown

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.79-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

Bug6228480_1696662427683.ree.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause-Internal Team

Slack conversation: @

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019a5d1f4f0cd37991
• Upwork Job ID: 1710593181054087168
• Last Price Increase: 2023-11-20
• Automatic offers:
• mollfpr | Reviewer | 27773918
• s-alves10 | Contributor | 27773920

Issue Owner

Current Issue Owner: @muttmuure

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~019a5d1f4f0cd37991

[melvin-bot]

Triggered auto assignment to @muttmuure (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 Contributor-plus team member for initial proposal review - @mollfpr (External)

[graylewis]

Proposal

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

Tasks that belong to an archived task report are still able to be completed/reopened

What is the root cause of that problem?

This actually seems to be a backend issue. This is evident due to the data coming from the API from the openReport call containing the property: "isDeletedParentAction": false. The reason the title on the task is briefly correct [shows {TaskName} (Archived)] is due to optimistic updates. The task report is never actually archived.

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

Backend code needs to be checked for bugs regarding the calculation of the isDeletedParentAction prop in the context of an archived workspace.

If a patch for the frontend is needed in the meantime, a line could be added to isDeletedParentAction which utilizes the persisted onyx store to look for the actionType "CLOSED" at the key for the report being opened.

[dummy-1111]

Proposal

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

The task report action in archived announce room is interactable and the task report is no longer archived after reopen the report

What is the root cause of that problem?

When we delete a workspace, we set the archived state of related reports here

App/src/libs/actions/Policy.js

Lines 93 to 102 in 389d7b0

	..._.map(reports, ({reportID}) => ({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: CONST.REPORT.STATE_NUM.SUBMITTED,
	statusNum: CONST.REPORT.STATUS.CLOSED,
	hasDraft: false,
	oldPolicyName: allPolicies[`${ONYXKEYS.COLLECTION.POLICY}${policyID}`].name,
	},
	})),

Task report is marked as archived as well. But when we reopen the task report, the backend returns state: 0, status: 0 again and so the task report returns to the normal state. This is one reason

After the workspace is deleted, we should disable the interaction of tasks. We disable the task using the below function

App/src/libs/actions/Task.js

Lines 889 to 903 in 389d7b0

	function canModifyTask(taskReport, sessionAccountID) {
	if (ReportUtils.isCanceledTaskReport(taskReport)) {
	return false;
	}
	if (sessionAccountID === getTaskOwnerAccountID(taskReport) || sessionAccountID === getTaskAssigneeAccountID(taskReport)) {
	return true;
	}
	// If you don't have access to the task report (maybe haven't opened it yet), check if you can access the parent report
	// - If the parent report is an #admins only room
	// - If you are a policy admin
	const parentReport = ReportUtils.getParentReport(taskReport);
	return ReportUtils.isAllowedToComment(parentReport);
	}

As you can see, we don't check if the parent report is an archived room. This is another reason

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

This issue requires both the backend and frontend fixes

1. Backend
   When a workspace is deleted, the backend should mark all the reports related to the workspace archived

2. Frontend
   We need to update the canModifyTask function above to check the parent report
   Update the above function as follows

function canModifyTask(taskReport, sessionAccountID) {
    if (ReportUtils.isCanceledTaskReport(taskReport)) {
        return false;
    }

    const parentReport = ReportUtils.getParentReport(taskReport);
    if (ReportUtils.isArchivedRoom(parentReport)) {
        return false;
    }

    if (sessionAccountID === getTaskOwnerAccountID(taskReport) || sessionAccountID === getTaskAssigneeAccountID(taskReport)) {
        return true;
    }

    // If you don't have access to the task report (maybe haven't opened it yet), check if you can access the parent report
    // - If the parent report is an #admins only room
    // - If you are a policy admin
    return ReportUtils.isAllowedToComment(parentReport);
}

This works as expected

What alternative solutions did you explore? (Optional)

[mollfpr]

Asking the internal team for the expected behavior of the task report when the parent report is archived.