Mahathi - fix: return project names for supplier performance Backend

[mahathiganimi]

Description

Related PRS (if any):

To test this backend PR you need to checkout the https://github.com/OneCommunityGlobal/HighestGoodNetworkApp/pull/5448 frontend PR

Main changes explained:

1. Updated the Supplier Performance projects endpoint to retrieve the distinct projectId values referenced by Supplier Performance records.
2. Added a lookup against the real Project collection so the endpoint returns project names instead of only project IDs.
3. Kept the existing Supplier Performance date-range filtering logic unchanged after confirming it was functioning correctly.
4. Verified the previous empty recent-date results were caused by stale 2024 development data rather than incorrect backend filtering.

How to test:

1. check into current branch
2. do npm install and ... to run this PR locally
3. Clear site data/cache
4. log as admin user
5. go to /bmdashboard/totalconstructionsummary
6. Open the tools and equipment tracking section
7. verify that you can see the supplier performance graph working correctly

Note:

Note that the local pre-commit related-test command may still fail because the unrelated reasonSchedulingController integration tests cannot connect to the local test database; the backend build itself succeeds.

[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

[Adit0717]

Tested the PR locally on Postman. Checked out the mentioned branches.

Tested the "api/suppliers/performance" endpoint with all filter combinations - projectId, startDate, endDate and everything works correctly. Found one minor issue.

Invalid projectId returns a 500 instead of 400 - Not reachable through the current UI, since the dropdown only sends valid project IDs - but the API route itself doesn't validate projectId format before passing it to mongoose.Types.ObjectId(). If it's called directly (e.g. via Postman) with a wrong or invalid ID, ObjectId() throws and it falls to the catch block, returning 500.

It would be more correct to validate projectId and return a 400 with a clear message (e.g. "Invalid projectId").

[DeepighaJ]

The filters work good except Tools by Availability section which couldn't be verified since frontend issue.

[linlin-husky]

Hi @mahathiganimi,

Thank you for your work on this PR! I tested the backend endpoints locally via Postman alongside frontend PR #5448.

Verified Points:

• Project Lookup (GET /api/suppliers/projects): Successfully returns 200 OK with an array of project objects containing proper projectName and _id pairs (e.g., "Orientation and Initial Setup", "XiaoFei test project 4").

• Performance Metrics (GET /api/suppliers/performance): Correctly returns aggregated metrics (e.g., onTimeDeliveryPercentage) for projectId=all across the specified date ranges.

• Required Parameter Check: The endpoint properly returns 400 Bad Request with "Missing required query parameters: startDate, endDate" when dates are omitted.

Areas for Improvement / Questions:

1. Handling Invalid projectId Format:

   • When querying GET /api/suppliers/performance?projectId=invalid_project_123&startDate=1970-01-01&endDate=2026-08-28, the endpoint returns a 500 Internal Server Error due to an unhandled CastError.

   • Could we add a format validation check (such as mongoose.Types.ObjectId.isValid(projectId)) when projectId !== 'all' and return a 400 Bad Request with an informative error message instead?

[vidiyala99]

Reviewed c4d2837 against the real supplier-performance data on the shared dev database (read-only).

Most supplier projects disappear from the list after this change. GET /api/suppliers/projects on the current backend returns 7 distinct projectIds. I matched them against both project collections:

• 2 exist in the HGN Project collection ("SiddharthTest" and "XiaoFei test project 4").
• 0 exist in the BM building projects (/api/bm/projects).
• The other 5 have no project document at all: 4 are seed placeholders (507f1f77bcf86cd799439011 to ...014) and 1 is a real-looking ID that matches neither collection.

The new Project.find({ _id: { $in: projectIds } }) only returns documents that exist, so the dropdown goes from 7 entries to 2. The records for the other 5 IDs are still in SupplierPerformance but can't be selected any more, and nothing tells the user they were dropped. That matches the earlier tester seeing names like "XiaoFei test project 4", which are general HGN test projects rather than building projects.

Two things worth settling:

1. Which collection supplier performance should point to. The model says ref: 'project', but this is a BM dashboard chart. If it's meant to use BM building projects, the lookup (and the seed data) should use that collection instead.
2. What to do with IDs that don't resolve. Returning them with a placeholder name (for example Unknown project (…9011)) instead of dropping them, or cleaning up the placeholder seed rows, would keep the dropdown and the data in sync.

Requesting changes so the project source is confirmed before this merges.

[vidiyala99]

Re-checked the updated branch (044d701, rebased onto current development) on a test server against the shared dev data (read-only), comparing it with development:

Endpoint	development	this PR
GET /api/suppliers/projects	7 entries, raw IDs only	3 named projects ("Orientation and Initial Setup", "SiddharthTest", "XiaoFei test project 4")
GET /api/bm/tools-availability/projects	stub {"message":"Get unique project IDs"}	1 building project ("Building 1")

What's new and works:

• projectId validation: GET /api/suppliers/performance?projectId=notanid now returns 400 Invalid projectId. instead of a cast error, and projectId=all still returns every supplier.
• Tool availability: both routes now reach the real controller instead of the placeholder responses, and the project list has names from BuildingProject.
• The debug console.logs are gone from the supplier controller.

Still open from my last review:

1. Supplier data for unresolved projects is still hidden. Four of the seven project IDs are the seed placeholders (507f1f77bcf86cd799439011 to ...014) and still have records: GET /api/suppliers/performance?projectId=507f1f77bcf86cd799439011 returns "Supplier A" at 95.8%. Because getProjectsWithSupplierData only returns IDs found in Project, those projects can no longer be picked in the dropdown, and nothing tells the user. Either keep them with a placeholder name (for example "Unknown project (...9011)") or remove the placeholder seed rows, so the list and the data agree.
2. Which project collection is right is still worth confirming: supplier performance looks names up in HGN Project, while tool availability (in this same PR) uses BuildingProject. Both are BM dashboard charts, so one of them is probably pointing at the wrong collection.

Note: src/startup/routes.js mounts toolAvailabilityRouter twice (lines 621 and 624) and also mounts bmToolAvailabilityRoutes under /api. That predates this PR, but it's worth tidying so it's clear which handler serves these paths.

Requesting changes for item 1.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[vidiyala99]

Re-tested the new commit b160af8 on a test server against the shared dev data (read-only GET requests only), together with the frontend OneCommunityGlobal/HighestGoodNetworkApp#5448 merged into current development, as Administrator.

My blocking item is fixed: supplier data for projects that aren't in Project is no longer hidden.

• GET /api/suppliers/projects now returns all 7 project IDs that have supplier data: the 3 named projects plus Unknown project (…9011) to (…9014) for the 4 seed IDs, sorted by name.
• Picking "Unknown project (…9011)" in the Supplier Performance dropdown shows Supplier A at 95.8%, the same as GET /api/suppliers/performance?projectId=507f1f77bcf86cd799439011 (screenshot 1). So the list and the data agree now.

Also checked:

• GET /api/bm/tools-availability/projects returns [{ projectId, projectName: "Building 1" }]; with the frontend, picking it loads Hammer, Power Drill and Circular Saw in Tools by Availability.
• projectId=notanid still returns 400 Invalid projectId., and projectId=all returns all 4 suppliers.
• The two updated suites (supplierPerformance.test.js, toolAvailabilityController.test.js) pass 27/27.

The Project vs BuildingProject question from my last review is still worth a quick confirmation from whoever owns the BM data, but it isn't blocking.

Approving the backend. (The frontend PR has a separate mobile layout issue, see my review there.)

Screenshot 1: 'Unknown project (…9011)' selected, Supplier A at 95.8% (matches the API)