[Adit0717]

Description

Related PRS (if any):

This frontend PR is related to the #2375 backend PR.
…

Main changes explained:

1. Fixed the "Review Week" dropdown to trigger a re-fetch with the correct Monday date for the selected week (current, 1 week ago, up to 4 weeks ago), replacing the previous behavior where the dropdown only displayed a label but never fetched data.

2. Added a trash icon button to each reviewer row that opens a RemoveReviewerModal - a confirmation dialog showing the reviewer name with Cancel and Remove options. On confirmation, a DELETE API call is made to permanently remove the reviewer's document from the weeklyGradings collection in MongoDB. The reviewer is then removed from local state - on page refresh they do not reappear. This deletion happens for the current week alone and the past records related to that particular user is untouched.

3. Added isCurrentWeek guard: Add Reviewer button, Add New / Remove buttons, and Save button are hidden when viewing a past week. Rows show a "Read only" label instead, preventing back-dating of data.

4. Fixed week-start date normalization - both fetch and save now use getWeekStart() (Monday of the current week), ensuring the MongoDB compound unique index { teamCode, date, reviewer } creates exactly one record per reviewer per
   week.
   …

How to test:

1. check into the frontend and backend branches
2. do npm install and run the app
3. Clear site data/cache
4. go to /pr-grading-dashboard
5. Week filtering: Verify only the current week's reviewers load on mount. Switch the dropdown to "1 Week Ago" - the table should re-fetch and show only records for that week's Monday date.
6. Read-only past weeks: With a past week selected, verify the Add Reviewer button, Add New button, Remove button, and Save button are all hidden. Rows should show "Read only" in the actions column.
7. Remove reviewer (current week): Switch back to Current Week. Click the trash icon next to a reviewer - a modal should appear with "Remove reviewer X from this week?" Click Cancel - the reviewer remains. Click Remove - the reviewer
   disappears from the table, a success toast appears, and a DELETE call goes to the backend.
8. Persistence check: After removing a reviewer, refresh the page - the reviewer should NOT reappear (document deleted from DB).

[netlify]

✅ Deploy Preview for highestgoodnetwork-dev ready!

Name	Link
🔨 Latest commit	6f79bf0
🔍 Latest deploy log	https://app.netlify.com/projects/highestgoodnetwork-dev/deploys/6ad2c4d606849e348fe5728f
😎 Deploy Preview	https://deploy-preview-5596--highestgoodnetwork-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[manavkheni1]

Tested locally with paired backend PR #2375. Confirmed week filtering works — switching "Review Week" to "2 Weeks Ago" correctly re-fetches and shows only that week's data. Read-only past weeks confirmed: with a past week selected, Add Reviewer, Add New, Remove, and Save are all hidden, with rows showing "Read only" instead. Remove reviewer flow confirmed working for the current week: added a reviewer, clicked Save to persist it, then used the trash icon — Cancel correctly left the reviewer in place, and Remove successfully deleted it with a success toast and a DELETE call to the backend. Persistence check passed — refreshing the page after removal confirms the reviewer does not reappear. No issues found.

[vidiyala99]

Tested c19a094 merged into current development (the merge is clean) with backend OneCommunityGlobal/HGNRest#2375 (2a78837, also merged into development) as Administrator on /pr-grading-dashboard, in dark mode. The save POST and the DELETE were intercepted in the browser and answered locally, so nothing was written to the shared dev database.

What works:

• Review Week now refetches with the right Monday: Current Week requests date=2026-10-05, 1 Week Ago 2026-09-28, and 4 Weeks Ago 2026-09-07, with the range shown under the dropdown ("Sep 7 - Sep 13") (screenshot 1).
• Past weeks are read-only: on 1 and 4 Weeks Ago, Add Reviewer and Save are hidden; they come back on Current Week.
• Save sends {"teamCode":"TeamA","date":"2026-10-05","gradings":[{"reviewer":"Review Probe","prsNeeded":2,...}]} for a reviewer added with 2 PRs needed.
• Remove reviewer: the trash button opens "Remove reviewer Review Probe from this week?" with Cancel/Remove (screenshot 2). Remove sends DELETE /api/weekly-grading?team=TeamA&date=2026-10-05&reviewer=Review%20Probe, removes the row, and shows "Reviewer "Review Probe" removed successfully."

Notes, not blocking for the frontend:

• The dialog says "Their past PR review history will remain visible in analytics." That's true for other weeks, but the backend deletes that week's whole document, including its versionHistory. Also, the backend route has no permission check yet. Both are in my OneCommunityGlobal/HGNRest#2375 review, so this shouldn't merge before that's fixed.
• Weeks here run Monday to Sunday ("Oct 5 - Oct 11"), while most of the app uses Sunday-start Pacific weeks. Worth confirming that's intended for PR grading.

Approving the frontend.

Screenshot 1: 4 Weeks Ago, read-only, Sep 7 - Sep 13

Screenshot 2: Remove Reviewer confirmation

[iAbhi001]

Tested the commit merged cleanly into development alongside backend PR #2375 as Admin on /pr-grading-dashboard in dark mode. Mocked the save POST and DELETE requests locally to avoid writing to dev data.

Everything on the frontend behaves properly:

• Week selection queries the correct Monday dates and displays proper date ranges underneath (screenshot 1).
• Past weeks lock down into read only mode, cleanly hiding Add Reviewer and Save until returning to Current Week.
• Save dispatches the expected payload format for added reviewers.
• Trash action pops a clean confirmation modal (screenshot 2), fires the DELETE call, drops the row from the view, and pops a success toast.

Non blocking frontend notes:

• The backend currently hard deletes the week document and lacks auth checks, so holding frontend merge until backend PR #2375 lands fixes for those makes sense.
• The Monday to Sunday calendar span here differs from the usual Sunday start used across the rest of the app, so worth verifying if that is intentional.

Frontend looks good to go, approving!

[AaditTrivedi]

Reviewed by Aadit Trivedi.

Reviewed the diff (5 files, no conflicts with development) alongside its backend, HGNRest #2375, where I've also requested changes.

Verified

• Removing a reviewer opens a confirmation modal (RemoveReviewerModal), the reviewer is removed from the list only after the DELETE succeeds, and success and failure are both reported with toasts.

Issues found

1. No permission check: the remove action is available to anyone who can open the grading dashboard, and the backend in #2375 doesn't check permissions either, so together any user could delete a reviewer's grading record. Please show the remove button only to users with the PR Dashboard edit permission (hasPermission), matching a permission check added on the backend.
2. PRGradingDashboard.jsx defines const TEAM_CODE = 'TeamA' (line 14), and the delete request sends team=${TEAM_CODE}, so a removal always targets team "TeamA" regardless of which team is being graded. If the hardcoded team predates this PR, the new delete still inherits it; it should use the currently selected team.

Pointer, not blocking

• The request URL is built from process.env.REACT_APP_APIENDPOINT directly; adding the endpoint to ENDPOINTS in URL.js would match the rest of the app.

Required action
Please gate the remove action behind the edit permission and use the selected team instead of the hardcoded "TeamA". Happy to re-review together with #2375.

[rahulrubugunday]

Tested locally on Aditya_fix_bug_remove-reviewer-weekly-grading_fe at c19a094 as DevAdmin, with backend on HGNRest#2375. No conflicts with development.

• Current Week: each reviewer row has a remove button. It opens the Remove Reviewer modal, and Remove deletes the row with a success toast. Used a test reviewer for this.
• Past weeks are read only: Save, Add Reviewer and the remove buttons are hidden.

Needs changes:

1. Past weeks don't show all their reviewers. 3 Weeks Ago (Sep 21 to 27) shows Abhi and AK-Test, but AK_test and AK_test_2 also have records saved on Sep 21 for TeamA and don't appear. Only records saved on the exact date the page requests show up.
2. The modal says "Their past PR review history will remain visible in analytics," but after Remove the grading record is gone from the database completely, so there's nothing left to show.

Requesting changes.

[sonarqubecloud]

Quality Gate passed

Issues
5 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

[Adit0717]

Following issues have been fixed in the latest commit:

1. Permission check - the remove button is now validated behind hasPermission('accessPRTeamDashboard'). The button only renders when isCurrentWeek && canEdit. The backend (PR #2375) also validates the same permission and returns 403 if unauthorized.
2. Hardcoded TEAM_CODE - removed. All three usages (GET fetch, DELETE call, save payload) now use selectedTeam state.
3. Modal text - "Their past PR review history will remain visible in analytics" refers to records from other weeks for that reviewer, which are unaffected by this delete. This week's record is removed (intentional - the feature is for accidental additions to the current week).
4. Fixed the timezone related issue by formatting the date using local date components (getFullYear/getMonth/getDate) instead of toISOString(), so the Monday date is always computed correctly regardless of time of day.

[AaditTrivedi]

Re-reviewed by Aadit Trivedi.

Both issues from my review are addressed: the dashboard now checks hasPermission('accessPRTeamDashboard') (canEdit) for the remove action, and requests use the selectedTeam state instead of the hardcoded TEAM_CODE = 'TeamA' constant.

Pointer, not blocking

• The backend, #2375, still needs its own permission check (and soft delete), since a frontend check alone doesn't stop a direct API call. These should merge together.

Approving.

[iAbhi001]

Re-tested locally on branch Aditya_fix_bug_remove-reviewer-weekly-grading_fe at commit 6f79bf0 with backend on companion PR #2375 as Admin on /pr-grading-dashboard. The updates in the recent commits properly address the earlier concerns: the remove action is now correctly protected behind the accessPRTeamDashboard permission check (isCurrentWeek && canEdit), the hardcoded TEAM_CODE = 'TeamA' has been replaced by the dynamic selectedTeam state across fetching, saving, and deletion, and computing Monday dates via local date components fixes previous timezone rollover shifts. Review week filtering, past-week read-only mode, and confirmation modal workflows all continue to operate smoothly on the client. Non-blocking reminder: ensure backend companion PR #2375 is merged concurrently so server-side authorization and soft-deletion behavior stay fully aligned with the frontend. Approving!

[vidiyala99]

Re-reviewed at 6f79bf0 (my earlier review was on c19a094, and it was dismissed).

Tested /pr-grading-dashboard in a browser with the component rendered on its own with a mocked store (an Administrator whose role has accessPRTeamDashboard) and the weekly-grading API mocked, so nothing touched a real database. The backend pair HGNRest#2375 is approved and I ran its controller against a local MongoDB.

Fixed since my last review:

• Remove now sends the requestor and the backend checks the permission. The DELETE was /weekly-grading?team=TeamA&date=2026-10-19&reviewer=Bob%20Smith with body {"requestor":{"requestorId":"user-123"}}. A rejected delete shows "Failed to remove reviewer. Please try again." and the reviewer stays in the list (screenshot 4).
• The route now requires accessPRTeamDashboard (routePermissions={RoutePermissions.prDashboard} instead of fallback), and the row actions (Add New, trash) only show for users who have it.
• The week start uses local date parts. I set the clock and time zone: Sunday 2026-10-25 23:30 in Los Angeles requests date=2026-10-19; Monday 2026-10-26 00:30 in Los Angeles and in Kiritimati (UTC+14) both request date=2026-10-26.
• Review Week refetches with the right Monday (Current Week 2026-10-19, 2 Weeks Ago 2026-10-05), and past weeks show "Read only" with Add Reviewer, Add New, trash and Save hidden (screenshot 2).
• The team code is no longer a constant in the request builders.

Remaining, none blocking:

1. No tests were added. The PR changes fetch, delete, permission and date logic but adds no vitest file, and src/components/PRGradingDashboard has none today. Even a small one for the week-start dates and the delete payload would guard this.
2. Add Reviewer and Save are not gated by canEdit. With a role that lacks the permission (my harness skips the route guard), the rows show "Read only" but both buttons are still visible. The route guard covers this in the app, so it is defense in depth only, and POST /weekly-grading/save has no permission check on the backend either.
3. The confirmation says "Their past PR review history will remain visible in analytics." Other weeks do stay, but the backend deletes that week's whole record, including its versionHistory.
4. At phone width the PR Actions column (Add New and trash) sits to the right of the visible area and the table scrolls sideways to reach it (screenshot 6).

Approving.

1. Administrator, current week (Oct 19 - Oct 25): Add Reviewer, Add New, trash and Save

2. Two Weeks Ago (Oct 5 - Oct 11): read only

3. Remove Reviewer confirmation

4. The delete was rejected (403): the error toast shows and Bob Smith stays listed

5. Dark mode

6. Phone width

[one-community]

Thank you all, merging!

[RohSrik]

I tested frontend PR #5596 locally along with the related backend PR #2375.

The Review Week dropdown works as expected. Switching from Current Week to previous weeks updates the reviewer table, and the interface correctly restricts editing for past weeks. The Add Reviewer, Add New, Remove, and Save controls are hidden when viewing previous weeks, with the actions column displaying a read-only indication.

For the current week, the Add Reviewer modal opens correctly and displays the Reviewer Name and PRs Needed fields. The trash icon also opens the Remove Reviewer confirmation modal, showing the selected reviewer's name along with Cancel and Remove buttons. I verified that clicking Cancel closes the modal without affecting the reviewer entry.

I also tested the interface in dark mode. The dropdown, table, read-only indicators, and modal elements are displayed clearly and consistently.

Overall, the tested controls, modal interactions, and UI behavior are working as expected.