Jaden - Fix: HGN Feedback Modal not showing due to missing render and endpoint (DONE Jaden)

[Jaden300]

Fix: HGN Feedback Modal not showing due to missing render and endpoint (DONE Jaden)- #5549

Problem

The HGN Feedback Modal (src/components/FeedbackModal/FeedbackModal.jsx) never appeared for users, showing no data.

Root cause

Two stacked bugs:

1. <FeedbackModal /> was commented out in Dashboard.jsx, so it was never rendered.
2. Even if rendered, it called ENDPOINTS.QUESTIONNAIRE_CHECK_MODAL, which did not exist. The resulting error was silently caught and the modal was forced closed.

Fix

• Imported and uncommented <FeedbackModal /> in Dashboard.jsx
• Added QUESTIONNAIRE_CHECK_MODAL to ENDPOINTS in URL.js, pointing at the new backend route added in HGNRest #2352
• Removed leftover debug console.log calls in handleSubmit

How to test

1. Check out this branch and the companion backend branch (HGNRest Frontend Release to Main [3.60] #2352), npm install, run both apps.
2. Log in as a user whose profile has no questionaireFeedback set (or has it set with foundHelpSomeWhereClosePermanently: false).
3. Go to the Dashboard - the Feedback Modal should appear automatically.
4. Fill in "Were we able to help you last week?", add a member with a rating, and Submit - modal closes, no console errors.
5. Reopen the Dashboard, click "Found help another way. Close Permanently" - modal closes and does not reappear on reload.
6. Confirm a user whose foundHelpSomeWhereClosePermanently is already true does not see the modal.
7. Verify light and dark mode.

Related

Backend companion PR: OneCommunityGlobal/HGNRest#2352

vod.mov

[netlify]

✅ Deploy Preview for highestgoodnetwork-dev ready!

Name	Link
🔨 Latest commit	6e5f37c
🔍 Latest deploy log	https://app.netlify.com/projects/highestgoodnetwork-dev/deploys/6aca9e2ce1c3c90008c5703c
😎 Deploy Preview	https://deploy-preview-5549--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.

[AaditTrivedi]

Reviewed by Aadit Trivedi.

Reviewed the diff alongside backend HGNRest #2352. I could not test the modal end to end, since #2352 is not merged and staging does not have the new /dashboard/questionaire/checkModal/:userId route.

Verified

• Re-enables <FeedbackModal />, which was commented out and is the cause of the modal not showing.
• Removes four leftover console.log statements.
• Adds the QUESTIONNAIRE_CHECK_MODAL endpoint matching the route in #2352.

Pointer, not blocking

• This depends on #2352, where I requested changes to its error handling. On a failed request the frontend currently receives a 200 response without showModal, so the modal silently won't appear; worth handling that case once the backend returns proper error codes.

Approving.

[vidiyala99]

Tested 6bee6fe with backend OneCommunityGlobal/HGNRest#2352 (732ebe5) as Administrator and Volunteer, in light and dark mode. The only write was one feedback submission from my own Volunteer test account.

The wiring works: with both branches, GET /dashboard/questionaire/checkModal/:userId returns showModal, and the Help Request Feedback modal renders on the Dashboard (screenshots 1 and 2, light and dark).

Issues:

1. The modal would show to almost every user, on every Dashboard load. The new check returns showModal: true unless the user has clicked "Found help another way. Close Permanently". It doesn't look at whether the person ever asked for help or when. I called the endpoint for 300 active users spread across the dev database: 298 got showModal: true. My Volunteer test account, which has never made a help request, sees "Were we able to help you last week?" on every visit:

   • Closing with × and reloading: the modal is back.
   • Submitting ("Yes" plus a comment, POST /dashboard/questionaire/feedbackrequest returned 200) and reloading: the modal is back (screenshot 3).

   So the only way to stop it is "Close Permanently", which also records that the person found help elsewhere, which isn't true for most users.

2. There's already a gated version of this check. HGNRest development has GET /api/helprequest/check-modal/:userId (helpRequestController.checkIfModalShouldShow). It returns shouldShow: true only when the user has a help request at least 7 days old with feedbackSubmitted: false, and not after a permanent close. The frontend already calls it from src/components/HGNHelpSkillsDashboard/FeedbackModal.jsx (ENDPOINTS.HELP_REQUEST_CHECK_MODAL). Please reuse that rule (or that component) instead of adding a second check that ignores help requests. At minimum, the new check needs to require an open help request and respect daterequestedFeedback, so a submitted feedback stops the modal.

3. The frontend can't tell an error from "don't show". OneCommunityGlobal/HGNRest#2352 returns HTTP 200 for failures: an invalid id gives 200 {"message":"Internal server error"}, and an unknown id gives 200 {"message":"User not found"}. FeedbackModal.jsx treats any response without showModal: true as "don't show", so real failures are silent. (Details in my OneCommunityGlobal/HGNRest#2352 review.)

4. No tests were added for the new endpoint or for the Dashboard rendering the modal.

The removed console.log calls and the new QUESTIONNAIRE_CHECK_MODAL entry look fine.

Screenshot 1: Volunteer dashboard, modal (light)

Screenshot 2: same, dark mode

Screenshot 3: modal back after Submit + reload

[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

[AaditTrivedi]

Re-reviewed by Aadit Trivedi.

The new commit replaces .find() with .some() for invalidActive and invalidInactive in FeedbackModal.jsx. These are used as true/false checks, and .some() returns a boolean directly, while .find() returns the matching item or undefined, so this is the correct method. Everything from my earlier approval still holds.

Approving.

[vidiyala99]

Re-tested at 6e5f37c with OneCommunityGlobal/HGNRest#2352 (732ebe5, no new commits since my 10/09 review) as Administrator and Volunteer, in light and dark mode. Submits were intercepted in the browser, so nothing was written to the dev database.

What the 3 new commits change:

• 6e5f37c .find() to .some(): works. A made-up name ("Notarealperson Xyz") is blocked with "Please select valid members from the dropdown only." (screenshot 4). A name picked from the dropdown passes validation and the modal closes on Submit. (Small note: isValidMemberName returns true when the name is not a valid user, so the name reads backwards. Renaming it to isInvalidMemberName would help the next reader.)
• c0fa9f0 "avoid masking real check-modal errors": the if/else became setIsOpen(Boolean(response.data?.showModal)). It's cleaner, but it behaves the same as before. Errors are still silent:
  • The backend still answers failures with HTTP 200: checkModal/not-an-id gives 200 {"message":"Internal server error"}, and an unknown id gives 200 {"message":"User not found"}. Both read as "don't show".
  • When I forced the check request to fail, the modal just doesn't appear, and the only trace is console.error('Error checking help request') (screenshot 5).
• 1485b96 adds netlify.toml (MISE_PYTHON_GITHUB_ATTESTATIONS = "false"). This is a repo-wide deploy setting unrelated to the modal. It's better as its own PR so maintainers can decide on it.

Still open (re-confirmed today):

1. The modal ignores feedback that was already submitted. My Volunteer test account submitted feedback on 10/06. Its profile shows questionaireFeedback.daterequestedFeedback: 2026-10-06, yet checkModal still returns showModal: true, and the modal opens on every Dashboard load (screenshots 2 and 3). Closing with × and reloading brings it back. When I tested on 10/05, 298 of 300 active users got showModal: true.
2. An existing, properly gated check isn't being used. For the same user, GET /api/helprequest/check-modal/:userId returns shouldShow: false, because it requires a help request at least 7 days old with feedbackSubmitted: false. The new check only looks at foundHelpSomeWhereClosePermanently.
3. Errors are indistinguishable from "don't show" (see above).
4. No tests for the endpoint or the Dashboard render.

Administrator (devadmin) correctly sees no modal (screenshot 1), but only because that account clicked "Close Permanently" earlier.

Requesting changes. The main fix belongs in OneCommunityGlobal/HGNRest#2352: show the modal only when there's an open help request, and stop showing it after a submit. Happy to re-test both PRs once that lands.

Screenshot 1: Administrator dashboard, no modal (dark)

Screenshot 2: Volunteer, modal still shows after feedback was submitted on 10/06 (dark)

Screenshot 3: same, light mode

Screenshot 4: made-up member name blocked by the .some() check

Screenshot 5: check request fails, modal silently missing, no message to the user