Aditya - Fix incorrect numbers of Total Projects on the Project page - #5484
Aditya - Fix incorrect numbers of Total Projects on the Project page#5484AdiDubbs wants to merge 1 commit into
Conversation
Total Projects counted whatever list was currently in the store, and the archive toggle replaced that list rather than adding to it, so the figure changed from 1189 to 458 simply by switching views. It should stay constant at the combined total in both. Archived projects now load into their own key rather than overwriting `projects`, which several other components read. Both lists are fetched on mount so the total is right before the archived view is ever opened, and the second card switches between the active and archived counts with a matching label. - Add FETCH_ARCHIVED_PROJECTS_SUCCESS so the archived fetch stops clobbering `projects` - Hold archived projects under `archivedProjects` in allProjectsReducer - Total is now projects + archivedProjects; the list reads from whichever array matches the current view - Overview takes a label and count for the second card, so the archived view reads "Archived Projects" rather than "Active Projects" - Add ARCHIVED_PROJECTS label - Two reducer tests covering that neither list overwrites the other
✅ Deploy Preview for highestgoodnetwork-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
iAbhi001
left a comment
There was a problem hiding this comment.
PR Review & Approval
I tested this PR locally on the Aditya_fix_total_projects_count branch. Everything functions as expected.
Testing Details:
- Default View:
- Total Projects correctly displays 1647 (
projects.length + archivedProjects.length). - The second card correctly renders Active Projects: 1105.
- The project list table renders active projects.
- Archived View ("Show Archived"):
- Total Projects remains constant at 1647 and does not drop.
- The second card dynamically updates its label and count to Archived Projects: 458.
- The project list table displays archived projects with the unarchive action available.
- Toggle Back ("Hide Archived"):
- Counts and labels smoothly revert to the active state without redundant re-renders or layout shifts.
- Tested under dark mode—styling, contrast, and card alignments look clean and consistent.
- Automated Tests:
- Ran
npm run test:changedand the reducer tests passed with no regressions.
Great job isolating the reducer state with FETCH_ARCHIVED_PROJECTS_SUCCESS and archivedProjects to prevent store overwrites.
LGTM! Approved. 🚀
DeMoliT1on
left a comment
There was a problem hiding this comment.
Tested locally for frontend PR changes branch Aditya_fix_total_projects_count and observed the following things.
Overall Assessment
Verified Working
- Total Projects Count: Stays constant at 1647 across both views.
- Dynamic Second Card Label: Displays "Active Projects: 1105" by default and switches to "Archived Projects: 458" when viewing archived projects.
- View Toggle Behavior: Switching via "Show Archived" / "Hide Archived" updates the project list context without corrupting global project counts.
- Theme Support: UI layout, button styling, and badge text render consistently across light and dark themes.
Screenshots
The PR successfully resolves the count mutation bug by separating active and archived project state keys. All requested test steps were verified locally in both light and dark modes with expected UI behavior. Approved!
DeepighaJ
left a comment
There was a problem hiding this comment.
- Verified the Projects page functionality as per the testing requirements.
- Confirmed that Total Projects remains unchanged when toggling between Show Archived and Hide Archived, while the second card correctly switches between Active Projects and Archived Projects with the appropriate count.
- Also verified that the table displays the correct non-archived and archived rows in each respective view.
Dark mode:
- The Show Archived button displays with a white/light background, which does not match the dark mode styling of the page. Please update the button styling to ensure it is consistent and readable in dark mode.



Description
On the Projects page, Total Projects changed depending on which view was open. It read 1189 in the default view and 458 after clicking Show Archived, when it should stay constant at the combined total of 1647. The second card also kept its "Active Projects" label in the archived view.
Original task
Note: the figures above are from Main. On the dev database there are 1189 active and 458 archived, so the expected total here is 1647. The behaviour is the same.
Related PRS (if any):
None. No backend changes.
Main changes explained:
state.allProjects.projects, andfetchAllArchivedProjectsdispatched the sameFETCH_PROJECTS_SUCCESSasfetchAllProjects, which replaces that array. Toggling the archived view therefore swapped the contents of the single list the counts were reading from. The counts were correct for whatever happened to be in the store; the store was the problem.FETCH_ARCHIVED_PROJECTS_SUCCESSand a matchingarchivedProjectskey on the reducer, so the archived fetch no longer overwritesprojects. That key is read by AddTaskModal, UserProfile, UserProfileAdd, UserProfileEdit, Reports and the WBS hook, so it should keep meaning "not archived".projects.length + archivedProjects.length, which does not change with the view. The project list itself reads from whichever array matches the current view.Overviewtakes a label and a count for the second card, so it reads "Archived Projects" with the archived count when that view is open, and "Active Projects" otherwise. Added anARCHIVED_PROJECTSlabel alongside the existing ones.How to test:
npm install, thennpm run start:localredis-server --daemonize yes, thennpm run devin HGNRest/permissionsonce so the role list loadsnpm run test:changedScreenshots or videos of changes:
Light mode
Dark mode
Note:
While tracing this I checked whether the archived list overwriting
projectscaused problems elsewhere. It largely does not: UserProfile and Reports both refetch unconditionally on mount, and AddTaskModal, which is guarded and would read the stale list, only looks up the current project's category and falls back to fetching that project's detail when it is not found. So the worst case there was a redundant request rather than a wrong value. Raising it here for the record rather than as a separate bug, since there is no symptom a user could report.