- Published
- October 12, 2025
- Last Updated
- October 19, 2025
- Author
- FdR - François
Student
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)
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.
- 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
- Fill in fields: name parts, dates, email, image, siblings, etc.
- Save → triggers validations and downstream logic
- On insert: User, Patient, Contact are created/linked
- On updates: name propagation, image sync, sibling sync, contact sync happen
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
- 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 withstudent_namefields will have name updates
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. |
Legend: 🟢 Allowed · ◻️ Not allowed
| Role | Read | Write | Create | Delete |
|---|---|---|---|---|
| System Manager | 🟢 | 🟢 | 🟢 | 🟢 |
| Academic Admin | 🟢 | 🟢 | 🟢 | 🟢 |
| Academic Assistant | 🟢 | 🟢 | 🟢 | 🟢 |
| Admission Officer | 🟢 | 🟢 | 🟢 | 🟢 |
| Academic Staff | 🟢 | ◻️ | ◻️ | ◻️ |
| Instructor | 🟢 | ◻️ | ◻️ | ◻️ |
| Counselor | 🟢 | ◻️ | ◻️ | ◻️ |
| Accreditation Visitor | 🟢 | ◻️ | ◻️ | ◻️ |
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 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 |
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.
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
- Construction of
Siblings list rules:
- A student cannot list themselves as sibling
- Duplicate sibling entries are pruned before save
These validations run server-side in the validate() method. Even if client UI prevents invalid data, server checks ensure data integrity.
- 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.
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.
- 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.
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.