Student

Overview

The Student doctype is one of the core entities in the ERP. Many other doctypes link to or depend on Student (e.g. enrollments, attendance, student log, guardians, etc.).
Main / Title field: student_full_name (constructed from first, middle, last name)

Why Student matters

This doctype is foundational. It not only captures demographic data (name, dates, contact) but also triggers creation and sync of User, Contact, Patient, and linked name propagation across other doctypes.


How to Create / Use
  1. There are many ways to get to students beside using the "awesome bar"; you can use the Academics workspace, the admission workspace or the counselor workspace (depending of your permissions or roles). In the UI: go to Academics → Students → New Student
  2. Fill in fields: name parts, dates, email, image, siblings, etc.
  3. Save → triggers validations and downstream logic
  4. On insert: User, Patient, Contact are created/linked
  5. On updates: name propagation, image sync, sibling sync, contact sync happen
View of Student Form
Student From with address
Name Changes Propagate

If you later change first/middle/last names, the system will automatically propagate the updated student_full_name into other doctypes that reference student_name, keeping your data consistent.


Student List View
View of Student List

Student List View


Relationships / Linked Doctypes
  • Student Patient — every Student gets a corresponding Patient record
  • User — if email is present, a User is created for the Student
  • Guardian — Info about the student's parents or guardians.
  • Contact — created/linked and Dynamic Linked
  • Student Sibling — child doctype representing sibling relationships
  • Other Doctypes referencing Student — via link_doctype = "Student" in many modules; those with student_name fields will have name updates
Propagation of Name Change

Any doctype that links to Student and has a student_name field will automatically receive updates to that field when the Student’s name changes — via update_student_name_in_linked_doctype().


Doctype Slug Description / Relationship to Student
Student Patient student-patient Each Student has a corresponding Patient record. Created in after_insert(), status synced when Student is disabled.
Student Group student-group Groups or cohorts of students (e.g. for classes, batches) that the Student may belong to.
Student Log student-log Historical log / audit trail of student changes (e.g. name changes, status changes) — useful for tracking.
Permissions

Legend: 🟢 Allowed · ◻️ Not allowed

Role Read Write Create Delete
System Manager 🟢 🟢 🟢 🟢
Academic Admin 🟢 🟢 🟢 🟢
Academic Assistant 🟢 🟢 🟢 🟢
Admission Officer 🟢 🟢 🟢 🟢
Academic Staff 🟢 ◻️ ◻️ ◻️
Instructor 🟢 ◻️ ◻️ ◻️
Counselor 🟢 ◻️ ◻️ ◻️
Accreditation Visitor 🟢 ◻️ ◻️ ◻️

Fields / JSON Structure

Here is a simplified table of the key fields for that doctype.

Field Name Type Purpose / Label Constraints / Notes
student_first_name Data First name
student_middle_name Data Middle name (optional)
student_last_name Data Last name
student_full_name Data Full name (auto-generated) Computed in validate()
student_date_of_birth Date Date of birth Must be < today; must precede joining date
student_joining_date Date Enrollment / joining date ≤ exit date if provided
student_exit_date Date Leaving / exit date Optional
student_email Email Email address If given, validated
enabled Checkbox / Int Active / inactive flag Syncs with Student Patient status
student_image File / URL Profile image link / path Renaming / moving logic applies
siblings Child table (Student Sibling) List of siblings No self-reference or duplicates allowed
Name Uniqueness Constraint

The field student_full_name must be globally unique (i.e. no two Students can have the same full name). If another record already has that name, save/validate will throw an error.


Validation and Constraints
  • validate() logic enforces:

    • Construction of student_full_name
    • Email format via validate_email_address() (if provided)
    • _validate_siblings_list() to eliminate self-references & duplicates
    • Date order checks: DOB < today, DOB < joining date, joining ≤ exit date
    • Name uniqueness: no other Student may already use the same full name
  • Siblings list rules:

    • A student cannot list themselves as sibling
    • Duplicate sibling entries are pruned before save
When validations run

These validations run server-side in the validate() method. Even if client UI prevents invalid data, server checks ensure data integrity.


Server-Side Logic (Python)
  • Auto-fills the student’s address and contact details so the form is ready to use.
  • On save, cleans up the record (names, basic checks) so data stays consistent.
  • On first save, automatically creates the student’s website login (if the email isn’t already a user), a basic health record, and a linked Contact—no manual linking needed.
  • Keeps things in sync on every update: student photo file/name, the linked Contact, whether the student is active/inactive, and sibling relationships.
  • Overall: you add/update a student once, and the system takes care of the related accounts, records, and links for you.
Best Practice for Sibling Edits

When editing siblings, make sure you manage both sides carefully (though system tries to auto-mirror). If a student is deleted or re-IDed later, sibling relationships might require manual maintenance.


Notes, Tips & Caveats
Performance & Edge Cases
  • Renaming student image moves files on disk — ensure file permissions and existence are valid.
  • Linked doctypes update via SQL — if there’s custom logic or triggers, test carefully.
  • Sibling sync avoids recursive save loops via frappe.flags._in_sibling_sync, but complex edits may still need attention.
Caution on Email / Contact Logic

If student_email is missing or changed, Contact or User creation/linking may break. Always ensure the email is valid when creating or editing a Student.