[HOLD for payment 2024-07-26] [HOLD for payment 2024-07-24] [HOLD for payment 2024-07-22] [HOLD for payment 2024-07-17] [Guided Setup Stage 2] [$500] Make the GBR on tasks at highest context and assign onboarding tasks to users

[anmurali]

We are currently deliberately not assigning the onboarding tasks to users because the GBRs on the tasks are at lowest context. I.e. each task is shown in the LHN with a GBR and it looks very noisy and potentially annoying. But we're losing out by doing this because after the first read, the user can ignore the chat with their onboarding tasks, or worse forget where it was originally and kinda lose motivation.

So, let's

• Make the GBR on tasks at highest context

1. if the user that the task is assigned to is in the parent chat where the task is shared, then the GBR is at that parent chat level
2. If the user that the task is assigned to is NOT in the parent chat where the task is shared, then the GBR is at the task level

• Assign all the onboarding tasks created for a user to said user

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c009eba2b6e9b0b1
• Upwork Job ID: 1787595574563139584
• Last Price Increase: 2024-07-15
• Automatic offers:
• cretadn22 | Contributor | 102769474

Issue Owner

Current Issue Owner: @puneetlath

[cretadn22]

Proposal

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

1. Make the GBR on tasks at highest context

• if the user that the task is assigned to is in the parent chat where the task is shared, then the GBR is at that parent chat level
• If the user that the task is assigned to is NOT in the parent chat where the task is shared, then the GBR is at the task level

2. Assign all the onboarding tasks created for a user to said user

What is the root cause of that problem?

This is not a bug, it requires to refactor the old logic. Currently, we use this logic to determined the Task report with GBR

App/src/libs/ReportUtils.ts

Line 2247 in ab1e924

if (isWaitingForAssigneeToCompleteTask(optionOrReport, parentReportAction)) {

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

1. Make the GBR on tasks at highest context

Initially, we must eliminate the outdated logic

App/src/libs/ReportUtils.ts

Line 2247 in ab1e924

if (isWaitingForAssigneeToCompleteTask(optionOrReport, parentReportAction)) {

followed by segregating the task report with GBR into a distinct variable

const assignedTaskReports: Array<OnyxEntry<Report>> = [];
if (requiresAttentionFromCurrentUserToAssignedTask(report, reportAction)) {
        assignedTaskReports.push(report);
} else {
    ...... <old logic>
}

The requiresAttentionFromCurrentUserToAssignedTask function will be designed as follows:

• If there exists a child report within the reportActions list, and this child report is categorized as a task report, with the condition that the managerID of the child report matches the currentUserID, then the function will return true
• If the report itself is a task report and does not have a parent report defined, the function will also return true
  (Note: In the context of task reports, report.managerID refers to the ID of the assignee)

2. Assign all the onboarding tasks created for a user to said user

When generating onboarding tasks, it's necessary to assign taskReport.managerID = currentUserID

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Auto-assigning issues to engineers is no longer supported. If you think this issue should receive engineering attention, please raise it in #whatsnext.

[allroundexperts]

Taking over!