Gayatri -Fix taskHours always returning 0 in getTaskAndProjectStats

[sawantgayatri19]

Description

Fixed a bug on the Total Org Summary dashboard where the "Hours Completed" chart's Tasks bar always showed 0 hours, regardless of the selected date range, while Project hours displayed correctly. The related "Task Completed" widget (Assigned/Completed counts) on the same page was affected by the same underlying issue.

The root cause was in getTaskHours inside overviewReportHelper.js. The MongoDB aggregation filtered time entries using:
This incorrectly excluded entries with entryType: 'person'. However, 'person' is a legitimate entryType for individual task-level time entries in this app — confirmed by the same categorization pattern already used elsewhere in this same file (line ~1043) and in the frontend (src/actions/timeEntries.js), which both treat 'default' and 'person' as equivalent task-level entry types. Since most real task time entries are logged with entryType: 'person', the filter was silently excluding nearly all of them, causing taskHours.count to always return 0.

Fixes ticket #1335 (P1/Total Org Summary: "Hours Completed" chart shows 0 hours for Tasks and very low hours for Project).

Related PRs (if any):

None.

Main changes explained:

• Updated src/helpers/overviewReportHelper.js: changed the getTaskHours aggregation's $match filter from entryType: { $nin: ['person', 'team', 'project'] } to entryType: { $in: ['default', 'person', null] }, matching the categorization pattern already used elsewhere in this file for task/individual-level time entries.

How to test:

1. Check into current branch (Gayatri-Fix-TaskHours-Zero)
2. Run npm install and npm run dev to run the backend locally
3. Run the frontend (HighestGoodNetworkApp) and log in as admin
4. Go to Dashboard → Total Org Summary (/totalorgsummary)
5. Check the "Hours Completed" chart — the Tasks bar should show real, non-zero hours whenever time has been logged in the selected date range (previously always showed 0)
6. Try switching between "Current Week," "Previous Week," and "Select Date Range" to confirm the Tasks bar responds correctly across different ranges
7. Verify the per-bar percentage labels match the footer text below the chart (e.g., "Hours Completed Split — X% Tasks | Y% Projects")

Screenshots or videos of changes:

Note:

Full backend test suite: 146/147 suites pass. The one failing suite (reasonSchedulingController.test.js) fails identically with and without this change — confirmed via git stash testing — due to a pre-existing local MongoDB connection timeout in the dev environment, unrelated to this fix. overviewReportHelper.spec.js (7/7 tests) passes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[DeepighaJ]

Unable to verify the functionality because navigating to /totalorgsummary results in a “Something went wrong” error page. Please investigate and fix the error so the page loads successfully and the requested functionality can be tested.

[devangsaraogi]

Hi @sawantgayatri19,

I reviewed and tested PR #2322 locally. I verified the taskandprojectstats endpoint across multiple date ranges and confirmed it returns consistent task/project hour totals and percentage calculations without errors.

I also reviewed the aggregation change and confirmed that including default, person and null matches the task-level time-entry categorization already used elsewhere in the application.

I investigated the previously reported /totalorgsummary “Something went wrong” issue as well. I reproduced the same page failure on the PR’s exact base commit, so it appears to be pre-existing rather than introduced by this change.

I wasn’t able to produce a local person entry in the available test data for a direct before/after comparison but I found no PR-specific regression or blocking issue and CI is passing.

Approved.

Fixed

[one-community]

Thank you all, merging!