Amaresh: Fix oversized TimeEntry/users response slowing the Dashboard

[amaresh2001]

Description

The Dashboard's "Team Member Tasks" widget calls POST /api/TimeEntry/users (getTimeEntriesForUsersList). That query populated personId with no field projection, so the entire UserProfile document (~60 fields including the password hash, weeklySummaries, badgeCollection, permissions, etc.) was attached to every time-entry row, not once per person. On teams with a lot of logged time, this multiplies into a multi-MB response and stalls the widget / Dashboard load.

The other three populates in the same function (projectId, taskId, wbsId) are already trimmed to the fields the response actually returns; this change brings personId in line.

The frontend only reads two fields off each row's userProfile: _id and email (in Timelog/TimeEntry.jsx, rendered via TeamMemberTasks.jsx), so the populate is narrowed to exactly those.

Link to issue

Related PRS (if any):

Backend-only. No frontend PR needed.

Main changes explained:

• Update src/controllers/timeEntryController.js in getTimeEntriesForUsersList, change .populate('personId') to .populate('personId', '_id email') so only the fields the client uses are returned instead of the full UserProfile per row.

How to test:

1. Check out this branch, run npm install, start the backend
2. Run the frontend against this backend, clear site data/cache
3. Log in as an admin user
4. Open the Dashboard, open DevTools → Network → Fetch/XHR
5. Find the POST /api/TimeEntry/users request
6. Expand any element of the response array and check userProfile it should now contain only _id and email (previously ~60 fields including password)
7. In the Team Member Tasks widget, activate a day filter (1/2/3/7 day) so individual time entries render; confirm entries still show date/hours/project/task and the edit-pencil / tangibility toggle still opens without a console error

Screenshots or videos of changes:

Before:

After:

	Before	After
Response body (uncompressed)	153,058 B	3,147 B
Transferred (gzip)	88.2 kB	1.3 kB
userProfile per row	full ~60-field document	{ _id, email }

~98% smaller. The same ratio applied to the reported production payload takes it from ~15 MB to roughly ~300 KB.

Note:

[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