Web - Task - Checkmark is not automatically updated when assignee is not set

[kbecciv]

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.2.3
Reproducible in staging?: y
Reproducible in production?: n
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 a chat with another account (i.e account B)
2. Inside the chat click on plus icon in the composer
3. Click on assign task
4. Insert a title and click on next
5. Confirm the task without selecting an assignee
6. From account A click on the checkbox of the recently created task
7. Observe the task on account B

Expected Result:

The checkbox should update and change to being marked as done on account B right after the task is marked as done from account A.

Actual Result:

The checkbox stays unmarked even after the task was marked as done from account A

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

Bug6291601_1701072874875.Recording.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~015113d6ac5682a883
• Upwork Job ID: 1729155989948653568
• Last Price Increase: 2023-11-27

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

[melvin-bot]

Triggered auto assignment to @dangrous (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[melvin-bot]

📣 @github-actions[bot]! 📣
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>

[kbecciv]

Production

Recording.5548.mp4

[dangrous]

hey @kbecciv can you try your production test again but don't assign the task? That seems to be the differentiator here. I'm seeing this bug replicated on production, so I want another set of eyes.

If it's indeed the case, this is a bug we should fix BUT it's not a deploy blocker. Thank you!

[abzokhattab]

I am also able to reproduce it on prod..

I guess this is a backend pusher issue

[mountiny]

This seems to be more so a backend issue, I will remove the deploy blocker label since its a last blocker

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor Plus for review of internal employee PR - @alitoshmatov (Internal)

[kavimuru]

@dangrous able to reproduce in production.

Recording.1656.mp4

[dangrous]

Great, thank you! We'll move forward with investigation but not as a blocker

[dangrous]

Okay so two weird things:

• participantAccountIDs when the task is completed from the creator's side only includes the creator. That's why it's not being sent. Not sure where this is occurring yet.
• If you try to complete the task from the other account, there's a silent 411 Insufficient privileges error. Once you click into the task report, though (rather than just the parent report), it's fine.

So I think somewhere the non-creator account is not being listed as a participant in the task on initial creation, even though they should be. I think that would explain both bugs. TBD on a fix

[dangrous]

Putting @thienlnam's comment from Slack here for posterity, will hopefully have time to chug through this this week:

Yeah I think we’d need to make sure all of those auth commands return the participants of the parent chat in $response['parentParticipants']['participantsAccountIDs'] , and then the parentReportActionID will need to have some more keys that represent the state of the task like childReportState or something similar (you’ll have to check what is returned currently)

[dangrous]

Haven't had time for this this week, I will likely be able to look into it mid-next week at the earliest (trying to finish out the whatsnext budgets project)

[melvin-bot]

@dangrous, @alitoshmatov Whoops! This issue is 2 days overdue. Let's get this updated quick!

[dangrous]

as noted, no time yet. will get there.

[melvin-bot]

@dangrous, @alitoshmatov Whoops! This issue is 2 days overdue. Let's get this updated quick!

[dangrous]

I was out unexpectedly this week, this is somewhat low priority so I will hopefully be able to grab it next week

[melvin-bot]

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

[dangrous]

no update since above, hoping to get to this later this week

[dangrous]

Maybe will have time this afternoon. But it's on my mind!

[dangrous]

@thienlnam Can we get your advice on this one? I've finally had the chance to look into it, and I have a couple questions. So there are two issues:

• The owner of a task completing it does not update the parent report for another user in the parent report.
  • But I'm confused as to why this is. Shouldn't this call to sendChildDetailsToParentAction send the status update to any participants in that report? Or does that not actually do what I think it does.
• Another user in the parent report does not have the permissions to complete a task, until they've opened it.
  • Above, I mentioned that it is a 411 error, but I just tried it again and am getting 666 Cannot complete action which means it's now happening before it gets to the actual check for permissions. So how can we tell auth that that user should have permissions for the task? Do we need to change something on the creation side?

[thienlnam]

Shouldn't this call to sendChildDetailsToParentAction send the status update to any participants in that report?

I think you might have mis-linked but that method should do exactly that - I would maybe check if this has the parent participants correctly when it is being called but it should be sending that pusher update

Another user in the parent report does not have the permissions to complete a task, until they've opened it.

This is what I'm working on in here https://github.com/Expensify/Expensify/issues/339618, it turns out there's a lot of issues that come up when a user is not shared on a report. I believe we can fix this by just sharing the user to the report in the peek() of all these commands. Haven't tested it yet but should hopefully solve this problem

[dangrous]

Oops yeah, I meant this - https://github.com/Expensify/Web-Expensify/blob/ac26ddb1425c58704478cc4f6d46347ff155d94c/lib/ReportAPI.php#L6089 - I looked at the stuff that it gets called with, and it had the right participants (i.e. everyone) but maybe wasn't sending the status along (but I don't really get why that would happen).

And great about the second question! I can focus on the first (unless you have ideas)

[thienlnam]

but maybe wasn't sending the status along (but I don't really get why that would happen).

Oh yes - you're on the right track here. That method needs to send back more parameters (i.e it's not passing back the childStateNum / childStatusNum)

[melvin-bot]

@dangrous, @alitoshmatov Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@dangrous, @alitoshmatov Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@dangrous, @alitoshmatov Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@dangrous, @alitoshmatov 10 days overdue. Is anyone even seeing these? Hello?

[dangrous]

Back now, will start trying to get this closed out tomorrow or later today

[dangrous]

Oh yes - you're on the right track here. That method needs to send back more parameters (i.e it's not passing back the childStateNum / childStatusNum)

Ah lovely, this was it! Putting up a PR now.

[dangrous]

Just tested this, it works nicely on prod now! I am going to close this - I don't believe any payment is due but @alitoshmatov (or anyone else?) please let me know if I am incorrect and we can reopen if needed!