Skip to main content

Student Details

The single-student admin surface. Tabbed view with Details, Parents, Account, and Token Requests. Used for editing personal info, swapping section/class, managing parent links, banning/unbanning, resetting passwords, and approving any in-flight token requests for that one student.

At a glance

Who can do thisAdmins & sub-admins with student-management permission
Where it livesAdmin panel → /dashboard/school/:id/students/:studentId
Reached fromThe students list at /dashboard/school/:id/students
Related featuresStudent Creation · Token Approval

Page layout

The header sits above the tabs and shows:

  • 72-px avatar with initials.
  • Full name (or fallback to email).
  • Quick tags: ID, Active vs Banned, Password Set vs Invite Pending, Class.
  • A "Resend Invite" button if the student hasn't set a password.

Step-by-step

Tab 1 — Details

Two cards, both with an Edit pencil that flips the card into an inline form.

Contact Information

FieldRequiredNotes
First Nameyes
Last Nameyes
EmailyesValidated as email
PhonenoFree-form
AddressnoMulti-line textarea

Save / Cancel buttons appear in the card's extra slot.

Academic Information

FieldRequiredNotes
ClassnoSearchable dropdown of school's classes
SectionnoDisabled until a class is picked; shows only sections of that class
Roll NonoFree-form
HousenoE.g. Red, Blue
Date of BirthnoDate picker, stored as YYYY-MM-DD
Language PreferencenoE.g. English, Hindi
Board(read-only)Inherited from the school

Picking a different Class resets the Section field. Saving propagates the new class+section to the student's profile.

Tab 2 — Parents

Lists 0–3 parent records (Mother, Father, Guardian — by relationship). Each parent renders as a card with:

  • Name, Email, Phone, Account status tag (Password Set / Invite Pending / No account).
  • Reset Password button per parent (admin-set password via a modal).

Below the cards is a dashed "Add Parent / Guardian" button. The available relationships are filtered: e.g. if the student already has a Mother and Father, only Guardian is offered; if all three exist, the button is hidden.

The Add Parent modal asks: Relationship (required), First Name (required), Last Name, Email (must be valid if provided), Phone.

Tab 3 — Account

Three stacked cards:

  1. Password Management — set or reset student's password. Also has a Resend Invite button if the password is still unset.
  2. Account Status — toggle Active ↔ Banned. Banned means the student cannot log in or use the platform; existing data is retained.
  3. Danger Zone — permanent delete with a confirm dialog.

Password modal validation:

  • New password ≥ 6 characters.
  • Confirm password must match.

Tab 4 — Token Requests

Same data as the main Token Approval queue, filtered to this student. Columns: Type · Amount · Purpose · Status · Date · Actions.

Pending rows show inline Approve / Reject buttons (Reject uses a Popconfirm). Non-pending rows show for actions.

A small badge on the tab label counts pending requests so the admin notices in-flight asks while editing the profile.

Bulk edit

The current student details page handles one student at a time. There is no admin-side bulk edit on this page. (The students list view has bulk import on creation but no bulk-edit grid.)

Edge cases & things to test

  • Edit cancel keeps prior values — start editing Contact, change a field, click Cancel — the card should re-render with the original values, not the typed-but-unsaved ones.
  • Class change without section — pick a new class, leave Section empty, save. The student should land in "no section" state and not crash list views that group by section.
  • Section dropdown after class change — switching class must clear any previously-selected section before showing the new options.
  • Adding a parent with an email already used by another user — should fail gracefully with an error toast, not throw.
  • Parent relationship ordering — UI should always render Mother/Father/Guardian in a consistent order regardless of the order parents were added.
  • Reset password while the student is logged in — the student's existing session should be invalidated on next request.
  • Banning vs deleting — banning preserves data and lets you unban later; deleting is permanent. Confirm the messaging makes that clear.
  • Resend Invite for a student who already set a password — the Resend Invite button should not be visible (only when isPasswordSet === false).
  • Token requests with pending count badge — approving a pending request should refresh the table and decrement the badge without leaving the tab.
  • Mobile — tabs and forms must be usable on a narrow viewport; the form grid should collapse to single column.
  • Back button — header back button returns to the school's students list, not browser history.
  • Stale data after edit — saving Contact or Academic should re-fetch the student so the header tags (e.g. class) update too.
  • Multi-school admin — confirm a sub-admin with access to only one school cannot navigate to a student in another school by URL guessing.