Important: When you begin this ticket, create a new branch from feat/registration-rework and not main. When you open a PR, open it into feat/registration-rework and not main.
Description
The new registration flow replaces the current self-report "have you registered previously" question with an actual database lookup. After a UoA student provides their UPI and student ID, the system checks whether they were a member in the previous year. If found, their existing details (email, first name, last name, faculty, programme, major) are displayed, and the user is allowed to change any details if they like. This ticket covers the backend lookup function only - integrating it into the form flow is a separate ticket.
Requirements
- Add a lookup function to the member repository (e.g.
findMemberByUpiAndStudentId) that queries the Member table
- Return the member's existing data if found,
null if not
- The function should be pure query - no side effects, no writes, no validation beyond "does this row exist"
Acceptance Criteria
Notes
This works against the existing schema - the new fields from ticket #83 don't affect whether a lookup works, only what data it returns. The function's return type may need updating once ticket #83's schema changes land, but the query and test structure won't change.
Important: When you begin this ticket, create a new branch from feat/registration-rework and not main. When you open a PR, open it into feat/registration-rework and not main.
Description
The new registration flow replaces the current self-report "have you registered previously" question with an actual database lookup. After a UoA student provides their UPI and student ID, the system checks whether they were a member in the previous year. If found, their existing details (email, first name, last name, faculty, programme, major) are displayed, and the user is allowed to change any details if they like. This ticket covers the backend lookup function only - integrating it into the form flow is a separate ticket.
Requirements
findMemberByUpiAndStudentId) that queries theMembertablenullif notAcceptance Criteria
nullwhen no match is foundNotes
This works against the existing schema - the new fields from ticket #83 don't affect whether a lookup works, only what data it returns. The function's return type may need updating once ticket #83's schema changes land, but the query and test structure won't change.