Bug Report
The public mentors page (/mentorship/mentors) shows mentors who do not belong to the currently open mentorship cycle. During an Ad-Hoc cycle it still lists mentors who have no ad-hoc availability (e.g. a long-term-only mentor, or a mentor whose ad-hoc availability is for a different month).
Steps to reproduce
- Open cycle is Ad-Hoc (e.g. July).
- In the admin portal, edit a mentor and remove the Ad-Hoc type (or leave a mentor whose ad-hoc availability is only for a different month).
- Open
/mentorship/mentors.
Expected: the mentor no longer appears (during an ad-hoc cycle the page should list only mentors available for ad-hoc in the current cycle month).
Actual: the mentor still appears.
Root cause
The page loads the unscoped default list. In src/pages/mentorship/mentors.tsx, selectedMentorshipType defaults to '' and the fetch only sends mentorshipTypes when it is present in the URL query, so the initial request is GET /api/mentors with no type filter. The backend, when given no mentorshipTypes, returns all active mentors regardless of the cycle.
The backend already scopes correctly — by type and month — when the filter is passed (GET /api/cms/v1/mentorship/mentors?mentorshipTypes=AD_HOC returns 0 for a mentor with no matching availability; month scoping was added in backend #707). It also already returns the open cycle in the response:
"openCycle": { "mentorshipType": "Ad-Hoc", "active": true }
The frontend simply never uses openCycle.mentorshipType to scope the default view.
Suggested fix (frontend)
On initial load, when the user has not explicitly selected a mentorship type (no mentorshipTypes in the URL), default the filter to openCycle.mentorshipType from the response, which triggers the already-correct type + month scoping on the backend. Keep the "All" option working: only apply this default once, so an explicit "All" selection still shows every active mentor.
This must live in the frontend (not the backend default), because only the client can distinguish "initial default view" from "user explicitly chose All" — both send no mentorshipTypes param.
Acceptance criteria
- During an Ad-Hoc cycle, the default
/mentorship/mentors view lists only mentors with ad-hoc availability in the current cycle month.
- During a Long-Term cycle, the default view lists only long-term mentors.
- Selecting "All" in the type filter still shows all active mentors.
- Selecting a specific type still works as before.
Bug Report
The public mentors page (
/mentorship/mentors) shows mentors who do not belong to the currently open mentorship cycle. During an Ad-Hoc cycle it still lists mentors who have no ad-hoc availability (e.g. a long-term-only mentor, or a mentor whose ad-hoc availability is for a different month).Steps to reproduce
/mentorship/mentors.Expected: the mentor no longer appears (during an ad-hoc cycle the page should list only mentors available for ad-hoc in the current cycle month).
Actual: the mentor still appears.
Root cause
The page loads the unscoped default list. In
src/pages/mentorship/mentors.tsx,selectedMentorshipTypedefaults to''and the fetch only sendsmentorshipTypeswhen it is present in the URL query, so the initial request isGET /api/mentorswith no type filter. The backend, when given nomentorshipTypes, returns all active mentors regardless of the cycle.The backend already scopes correctly — by type and month — when the filter is passed (
GET /api/cms/v1/mentorship/mentors?mentorshipTypes=AD_HOCreturns 0 for a mentor with no matching availability; month scoping was added in backend #707). It also already returns the open cycle in the response:The frontend simply never uses
openCycle.mentorshipTypeto scope the default view.Suggested fix (frontend)
On initial load, when the user has not explicitly selected a mentorship type (no
mentorshipTypesin the URL), default the filter toopenCycle.mentorshipTypefrom the response, which triggers the already-correct type + month scoping on the backend. Keep the "All" option working: only apply this default once, so an explicit "All" selection still shows every active mentor.This must live in the frontend (not the backend default), because only the client can distinguish "initial default view" from "user explicitly chose All" — both send no
mentorshipTypesparam.Acceptance criteria
/mentorship/mentorsview lists only mentors with ad-hoc availability in the current cycle month.