[bfire9989]

Description

The PR grading screen (/pr-grading-screen) was broken — it always showed mock data instead of real data. The root cause was a field name mismatch between two collections: weeklyGradings used teamCode while prGradingConfigs used teamName. The frontend reads teamName from the config and passes it as the ?team= query param, but the backend was querying by teamCode, so every request returned an empty array and the frontend fell back to fake data.

This PR fixes that mismatch and adds the remaining backend capabilities needed for the grading screen to work end-to-end in production.

Implements: PR Grading Screen backend support

Related PRs:

This backend PR is related to the frontend PR #5414. To test this backend PR you need to checkout frontend PR #5414.

Main changes explained:

• Update src/models/prAnalytics/weeklyGrading.js — renamed field teamCode → teamName in the schema and updated the compound unique index to match

• Update src/controllers/prAnalytics/weeklyGradingController.js — replaced all teamCode references with teamName, changed ?date= param to ?weekStart= for 7-day range queries, added Sunday midnight UTC normalization on save to prevent duplicate records, added deleteReviewerGrading handler

• Update src/routes/prAnalytics/weeklyGradingRouter.js — registered new DELETE /api/weekly-grading/reviewer route

• Update src/controllers/prAnalytics/prGradingConfigController.js — added syncReviewers method that auto-populates reviewerNames in team configs by querying SQ submissions (hgnFormResponses), excluding users already on a dev team (teams.members), splitting by last name A–M / N–Z, and calculating prsNeeded from userProfile.weeklycommittedHours

• Update src/routes/prAnalytics/prGradingConfigRouter.js — registered new POST /api/pr-grading-config/sync-reviewers route, updated constructor to accept UserProfile, HgnFormResponse, and Team models

• Update src/startup/routes.js — passes userProfile, hgnFormResponses, and team models to prGradingConfigRouter

• Create src/controllers/prAnalytics/weeklyGradingController.test.js — 22 unit tests covering all three controller methods

• Create src/controllers/prAnalytics/prGradingConfigController.test.js — 22 unit tests covering all four controller methods including sync logic

• Create docs/pr-grading-screen-backend-changes.md — full documentation of all changes, reasoning, DB migration commands, and outstanding items for the next developer

---

How to test:

1. Checkout this branch
2. Run npm install and start the server with npm start
3. Checkout the frontend PR #XXX and run the frontend
4. Log in as an Administrator or Owner
5. Navigate to /pr-grading-screen
6. Verify the team switcher shows Team 1 and Team 2 from the config
7. Verify that reviewer rows are populated with real data — not mock names like "Abi, Abdel, Anand". If it is a fresh week with no saved data, rows should be bootstrapped from the config's reviewerNames
8. Add a PR number to a reviewer row, grade it, and hit Save — verify the record appears in db.weeklyGradings with a Sunday-midnight UTC date
9. Hit Save again on the same week — verify no duplicate document is created (the same document should be updated, not a new one inserted)
10. Switch to a previous week in the dropdown — verify the table updates to show that week's saved data
11. Delete a reviewer — verify their record is removed from the database
12. Run npm test — verify all tests pass
13. Also verify all changes in the following MongoDB collections:

• weeklyGradings — the main one. Check that saves create/update records correctly, dates are Sunday-midnight, teamName field exists (not teamCode), and deletes remove the right documents
• prGradingConfigs — check that reviewerNames and reviewerCount get updated correctly after the sync endpoint runs
• hgnFormResponses — read-only for this PR. The sync reads from here to find who has submitted the SQ
• teams — read-only for this PR. The sync reads from here to find who has been promoted to a dev team
• userProfiles — read-only for this PR. The sync reads firstName, lastName, and weeklycommittedHours from here to build the reviewer list and calculate prsNeeded

Note on the database: The dev database migration has already been run. No manual DB steps are needed to test this PR on the dev environment. Before deploying to production, the migration commands documented in the PR-changes doc must be run by whoever handles the production deployment.

---

Note:

• POST /api/pr-grading-config/sync-reviewers assumes "promoted to a dev team" means the user's _id appears in teams.members.userId. If the promotion tracking mechanism changes in the future, this query needs updating.
• Full documentation of all changes, DB migration commands, and outstanding items is in a separate PR changes doc that can be obtained on request from the Owner.

[sonarqubecloud]

Quality Gate failed

Failed conditions
E Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[iAbhi001]

PR Review & Local Testing Update

I pulled down frontend branch pr-grading-screen-frontend and backend branch pr-grading-screen-backend to test the changes locally.

When running the frontend test suite (npm test), I encountered 17 failing tests across 3 test files:

Test Files  3 failed | 314 passed | 1 skipped (318)
Tests       17 failed | 2123 passed | 14 skipped (2154)

[sawantgayatri19]

Summary of Changes Reviewed:
Schema Unification: Verified schema alignment from teamCode to teamName in weeklyGrading.js and updated compound unique indexes.

Controllers & Routes: Checked refactored endpoints and controller methods in weeklyGradingController.js, weeklyGradingRouter.js, prGradingConfigController.js, and prGradingConfigRouter.js, including Sunday midnight UTC date normalization and the POST /api/pr-grading-config/sync-reviewers sync logic.

Testing: Confirmed inclusion of new unit test suites covering the controller methods and synchronization logic.

Current Blockers & Action Items:
SonarQube Quality Gate Failed: The SonarQube Cloud Analysis reported an E Security Rating on New Code violation that must be fixed by the author.

Local Test Failures: As noted by iAbhi001, pulling down this backend branch alongside frontend PR #5414 results in 17 failing tests during local execution that need to be resolved.

[sitaram1921]

Hi Rithika,

I reviewed this against development and exercised the endpoints locally. The core diagnosis in your description is right, the teamCode / teamName mismatch really was why the screen fell back to mock data, and the write-up is clear. A few things need sorting before this can go in.

Note I could not follow your test steps end to end: the paired frontend #5414 does not compile. routes.jsx ends up importing PRGradingDashboard twice (the branch adds it at line 162 while development already has it at line 200), which is a Babel parse error in the app router, so no page loads. That is a #5414 issue and I will raise it there, but it does mean the grading screen itself is untested.

[RuthwikHM]

The tests were passing but I was unable to review the behaviour with the UI. See this for more info.

[iAbhi001]

PR Review & Local Testing Approval

I pulled down and tested backend branch pr-2256 alongside frontend PR #4608.

Local Execution & Setup:

• Server started successfully on port 4500 with MongoDB connected.
• Verified test suite and local endpoints.

Verified Backend Functionality:

• Issue Tracking Aggregations: Tested data fetching for both Longest Open and Most Expensive issue endpoints.
• Model Reference Fix: Confirmed the injuryIssue schema reference update to buildingProject allows project filtering to return proper data instead of empty arrays.
• Query & Filter Parameters: Verified query params (projectId, startDate, endDate) handle aggregation criteria accurately for specific project IDs as well as 'all'.

Approving changes.

[vidiyala99]

Reviewed 4861598. The PR's suites pass (prGradingConfigController.test.js + weeklyGradingController.test.js, 44/44). They start from an empty in-memory database, though, so they don't cover what happens to a database that already has weeklyGradings. I tested that case with a small probe against an in-memory MongoDB set up the way existing databases are today (the old { teamCode, date, reviewer } unique index plus one old-schema document), using this branch's WeeklyGrading model:

1. Existing grades become invisible. The old document (teamCode: "Alpha") is not found by WeeklyGrading.find({ teamName: "Alpha" }), which returns 0. Every grade saved before this change would disappear from the grading screen. A migration that copies teamCode into teamName (or $renames it) is needed.

2. The old unique index breaks saves for a second team. Renaming the field in the schema doesn't drop teamCode_1_date_1_reviewer_1 from MongoDB; Mongoose only adds the new indexes. New documents have no teamCode, which that index treats as null. Saving reviewer "Bob" for 2026-10-11 under team "Alpha" works, but then saving "Bob" for the same date under team "Beta" fails:

   E11000 duplicate key error ... index: teamCode_1_date_1_reviewer_1 dup key: { teamCode: null, ... }
   

   The same migration should drop the old index (db.weeklyGradings.dropIndex('teamCode_1_date_1_reviewer_1')).

3. The branch is 514 commits behind development, and the same controller is also being changed in #2077 (duplicate PR numbers, which still uses teamCode). Please merge development and coordinate with #2077, so whichever lands second doesn't reintroduce teamCode.

Requesting changes for items 1 and 2.

[vidiyala99]

Re-tested the new head 0f1c128 ("support legacy weekly grading team codes") with a probe through the controller, against an in-memory MongoDB set up like an existing database (the old unique { teamCode, date, reviewer } index plus one old-schema grade with teamCode: "Alpha" only):

Check	4861598 (my last review)	0f1c128
Old grade shows up for team Alpha (getWeeklyGrading, week of Oct 4)	not found	found (Alice)
Save reviewer Bob for Oct 11 under Alpha, then under Beta	Beta failed with E11000 ... teamCode_1_date_1_reviewer_1 dup key: { teamCode: null }	both 200
Save Alpha/Alice/Oct 4 again (updating the old grade)	n/a	200, still one document, now with teamName and teamCode both "Alpha", version 2
Delete Alpha/Alice for that week	n/a	200, document removed

So both of my items are fixed without a migration: reads and deletes match either field, and every save writes teamCode alongside teamName, so the old unique index never sees null. Updating an old grade also upgrades it in place. The PR's suites pass (prGradingConfigController.test.js + weeklyGradingController.test.js, 45/45, including the new legacy test), and the branch now includes development, and (per the last two commits) the unrelated task controller change is gone.

Two small follow-ups, not blocking:

• The schema comment says teamCode stays "until the production migration runs". It would help to open a tracking issue for that migration (copy teamCode into teamName, then drop teamCode_1_date_1_reviewer_1), so the dual-field code can be removed later.
• #2077 changes this same controller; whichever merges second should keep the $or reads and the teamCode write.

Approving.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud