[Due for payment 2025-05-20] [$250] Error in archived task "Set up categories" when disabling category in another workspace

[mitarachim]

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: 9.1.33-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: No, reproducible on hybrid only
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Log in with a new Gmail account (don't use + account).
3. Click Skip on work email step.
4. Select Manage my team's expenses.
5. Select 1-10 employees > Continue.
6. Select any accounting software > Continue.
7. Go to Account > Workspaces.
8. Delete the workspace.
9. Create a new workspace.
10. Go to workspace settings > Categories.
11. Disable any category.
12. Note that there is task complete sound in the background after disabling the category.
13. Go back to Inbox.
14. Open the task report "Set up categories".

Expected Result:

The task report "Set up categories" should not be marked when the original workspace is deleted and category in another workspace is disabled.

Actual Result:

The task report "Set up categories" is marked when the original workspace is deleted and category in another workspace is disabled.
As a result, the task report shows the error "You don't have permission to take the requested action" because the task report is archived.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6815851_1745890407417.20250429_092511.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021917138863048883245
• Upwork Job ID: 1917138863048883245
• Last Price Increase: 2025-04-29
• Automatic offers:
• truph01 | Contributor | 107183854

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @kadiealexander

[melvin-bot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @robertjchen (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-29 04:33:46 UTC.

Proposal

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

Error in archived task "Set up categories" when disabling category in another workspace

What is the root cause of that problem?

This happen when we try to complete an onboarding task when we disable a category but we actually not checking if the report has been archived/ onboarding workspace has been deleted here

App/src/libs/actions/Task.ts

Lines 1281 to 1283 in bd0f3f2

	if (taskReport) {
	if (taskReport.stateNum !== CONST.REPORT.STATE_NUM.APPROVED || taskReport.statusNum !== CONST.REPORT.STATUS_NUM.APPROVED) {
	return completeTask(taskReport);

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

We should add isArchivedReportWithID here

  if (!ReportUtils.isArchivedReportWithID(taskReport?.reportID) && (taskReport.stateNum !== CONST.REPORT.STATE_NUM.APPROVED || taskReport.statusNum !== CONST.REPORT.STATUS_NUM.APPROVED)) {

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

We can check if the category belong to same workspace/ onboarding workspace, before calling completeTask

here

App/src/libs/actions/Task.ts

Lines 1282 to 1284 in bd0f3f2

	if (taskReport.stateNum !== CONST.REPORT.STATE_NUM.APPROVED || taskReport.statusNum !== CONST.REPORT.STATUS_NUM.APPROVED) {
	return completeTask(taskReport);
	}

[melvin-bot]

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

[melvin-bot]

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

[truph01]

Proposal

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

• Error in archived task "Set up categories" when disabling category in another workspace

What is the root cause of that problem?

• In
  

  App/src/libs/actions/Task.ts

  Line 1279 in 3477a29

  if (taskReportID) {

  
  we don't check whether user can mark the task as complete or not.

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

• We should use canActionTask:

function getFinishOnboardingTaskOnyxData(taskName: keyof OnyxTypes.IntroSelected): OnyxData {
    const taskReportID = introSelected?.[taskName];
    const taskReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${taskReportID}`];
    if (taskReportID && canActionTask(taskReport, currentUserAccountID)) { // Consider passing 3rd, 4th params.
        if (taskReport) {
            if (taskReport.stateNum !== CONST.REPORT.STATE_NUM.APPROVED || taskReport.statusNum !== CONST.REPORT.STATUS_NUM.APPROVED) {
                return completeTask(taskReport);
            }
        }
    }

    return {};
}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Add test for getFinishOnboardingTaskOnyxData.

What alternative solutions did you explore? (Optional)

[hungvu193]

I'll review in the morning

[hungvu193]

Thanks for the proposals, everyone.
Given that we can complete the tasks with the secondary account and can't cancel the tasks, I'm aligned with @samranahm 's proposal here.

🎀 👀 🎀 C+ reviewed

[hungvu193]

@truph01 My 2 cents here:

Both proposals have the correct root cause, and the solutions are quite similar.

canActionTask is generally used, it also contains the logic of cases that never happened with the onboarding tasks (is expense report,is canceled or not the assignee/owner task). Please correct me if I'm wrong.

It was always a hard decision for me to select between the correct fix and the correct fix that has been generally used inside the App.
I think we can let the Internal Engineer decide? Thanks for understanding 😄

[truph01]

Thanks @hungvu193. The 2nd point I think we should consider is that my proposal has the automated tests, which can make sure a similar bug doesn't appear in the future.

I think we can let the Internal Engineer decide? Thanks for understanding 😄

Anyway, @robertjchen All yours!

[melvin-bot]

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

[robertjchen]

👀

[samranahm]

@robertjchen Let me know if you need any explanation on #61006 (comment), thank you

[robertjchen]

Thanks for the discussions here! Having evaluated both proposals, I agree that it's pretty close one @hungvu193 . However, I think I'll come down on the side of @truph01 given that we'll be adding a test 🙏

[melvin-bot]

📣 @truph01 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[samranahm]

@robertjchen I think we should fix the actual root cause that was pretty simple (ignore the completeTask when the report has been archived) the chosen proposal suggest to check canActionTask that has many functions that are not relevant and can cause the regression.

I'll add the test in my solution, could you please take a look again?

[truph01]

Thanks @robertjchen. I am working on it and will open PR soon

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.44-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: Error in archived task Set up categories #61393

If no regressions arise, payment will be issued on 2025-05-20. 🎊

For reference, here are some details about the assignees on this issue:

• @hungvu193 requires payment through NewDot Manual Requests
• @truph01 requires payment automatic offer (Contributor)

[melvin-bot]

@hungvu193 @kadiealexander @hungvu193 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[kadiealexander]

Payments needed:

• - Contributor: @truph01 paid $250 via Upwork (offer)
• - Reviewer: @hungvu193 owed $250 via manual request

@hungvu193 please complete the checklist!

[hungvu193]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: https://github.com/Expensify/App/pull/60608/files#r2099600075

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: N/A

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal

Test:

1. Go to staging.new.expensify.com
2. Log in with a new Gmail account (don't use + account).
3. Click Skip on work email step.
4. Select Manage my team's expenses.
5. Select 1-10 employees > Continue.
6. Select any accounting software > Continue.
7. Go to Account > Workspaces.
8. Delete the workspace.
9. Create a new workspace.
10. Go to workspace settings > Categories.
11. Disable any category.
12. Note that there is task complete sound in the background after disabling the category.
13. Go back to Inbox.
14. Open the #admin room of the workspace that you've just deleted.
15. Verify that Set up categories task is archived and not marked as completed.

Do we agree 👍 or 👎