One parent login for all siblings¶
Status: in review, 3 October 2026. Code: webapp PR stacked on #1835 (two-parent registration with a primary contact).
Why this exists¶
- Who asked: the founder, directly. No customer ticket or interview names this yet, so treat it as founder-driven.
- Observed pain: a parent with two children enrolled could end up with two logins, or with the second child not linked at all, and had to switch accounts to see each child. The code confirmed several ways this happens. The same mobile number typed as
+91 98450 00000and9845000000made two accounts. A child at a second campus of the same group could not be linked. The parent import failed a sibling row with "phone already exists". A phone match was linked across unrelated institutions with no check. - Cost of not doing it: each sibling means another login and another credential SMS, and support asks to merge accounts. The cross-institution match also put children's records at risk: a mistyped number could link a child to a stranger's parent account.
- Validated or a guess: the defects are validated in code and tests. Demand for siblings at different campuses is a guess until a group customer with a school and a PU college confirms it.
- How we'll know it worked: a parent of siblings logs in once and sees every child, with the right campus on each. If we removed it a week after shipping, those parents would ask why their second child disappeared or why they need two passwords.
How admission forms in India handle parents¶
Desk research done before building, to check the #1835 registration form against real practice:
- UDISE+ (Student Profile 2025-26) records mother's, father's and guardian's names separately. It has one mobile (4.1.10a) and one alternate mobile (4.1.10b) "of Student/Parent/Guardian", and parent education on a 6-level scale (4.3.12). It does not ask for occupation or income.
- CBSE Class 9/11 registration needs the full mother's and father's/guardian's names, because they print on board certificates.
- Karnataka SATS keeps father's, mother's and student's mobiles separately.
- Private school forms (e.g. DPS, AKSIPS) capture a full block per parent: qualification, occupation, income, mobile and email. They also have a "single parent" flag and a "sibling studying in this school" table.
- School ERPs in India (Entab CampusCare, Fedena) give one parent login per family, keyed on the registered mobile. Entab treats a child as a sibling when the number matches either the father's or the mother's mobile. OpenEduCat gives separated parents independent accounts.
What this means for #1835:
| #1835 behaviour | Matches practice? | Note |
|---|---|---|
| Father and mother each with name + phone, email optional | Yes | |
| "Details not available" with an office-only reason | Mostly | CBSE still needs the parent's name on certificates when that parent is deceased. Hiding the name field when "not available" is ticked loses it. |
| Up to 2 extra guardians | Yes | Matches the "local guardian" block. |
| One primary contact whose phone is the parent login | Yes | Same as the mobile-keyed family login in Indian ERPs. |
| Primary contact's email required | Stricter than practice | Many parents have no email, and government forms make email optional. The invite flow currently needs email. Revisit with SMS invites. |
| Alternate / WhatsApp mobile removed | Partly | UDISE asks for an alternate mobile. The other parent's phone can fill it, but a UDISE export must derive it. |
| No qualification / occupation / income | Gap | UDISE needs parent education. KVS, KCET and private schools ask for occupation and income. Belongs in a follow-up. |
The rule¶
One guardian login per family per organisation, keyed on the primary contact's mobile.
- The mobile is normalised to its last ten digits, and older accounts stored as
+91…,91…or0…still match. - Matching covers every campus of the organisation (a trust's school and PU college). It never crosses organisations: a parent account at an unrelated institution with the same number is never reused.
- Linking is automatic only within one campus. A match at a sibling campus is linked only after a person confirms it, because a typed phone number alone doesn't prove the account belongs to this family.
- A number that belongs to a staff member, or to a parent at another organisation, gets no parent login. The student is still admitted or created.
Where it applies:
| Path | Behaviour |
|---|---|
| Campus admit (#1835) | If the primary contact's number already logs in a parent anywhere in the group, admit stops and asks. The prompt names the campus where that account was made. Staff link only after checking with the parent, as #1835 already does. |
| Add student and student CSV (core) | Reuses the sibling's parent login silently when the parent is at the same campus, with normalised numbers. A match at a sibling campus is reported in the import result and not linked. |
| Parent CSV import | A row whose parent already has a login at this campus is linked to that login, not failed. |
| Admin "link child to parent" | Org admins can link a child at any campus of the group, after checking with the parent. Campus admins still only link their own students. |
| Campus guardian editor | Accepts a parent login from this campus, and keeps a sibling-campus parent already confirmed at admit. It never makes a new cross-campus link. |
Attendance: a parent can open attendance when any of their children's campuses runs it, and each child's record follows that child's campus settings.
What the parent sees: every parent page (dashboard, courses, assignments, attendance) shares one child switcher. The child picked on one page stays picked on the next, and when siblings are at different campuses each child shows its campus. Attendance for a child at another campus reads in that child's campus context, after the link check passes.
Policy unchanged: the Campus portal shows guardians only children at K-12 and PU campuses. Degree, engineering and university students deal with the institution directly, so "school and college" siblings in practice means the school and the PU college of a group.
Non-goals¶
- Merging families that already have two logins. A one-off merge needs care (whose password survives, notifying the parent), so it is a separate change.
- A second login for the other parent. One login per family for now; separated parents who need separate access are a later decision.
- Matching on the other parent's number. Entab does this; we key only on the primary contact, which is what was asked. See rejected alternatives.
- Parents across organisations. Two unrelated institutions never share a parent login, even for the same family.
- Teacher-parents. Someone whose number is already their staff username gets no parent login. Fixing that needs one user to hold two roles (the roles and permissions work).
Rejected alternatives¶
- Match on any parent's number on the form (the Entab approach). It catches families who registered the father on one child and the mother on the other. Rejected for now because one admit could then match two different accounts, and the confirm step would need to pick one. Revisit if staff report split families.
- Match across the whole platform. Simplest, and what the old code did, but a mistyped number would attach a child to a stranger at another school. Not acceptable for minors' data.
- Auto-link at admit without asking. Fewer clicks, but the phone on an application is applicant-supplied. #1835's confirm step stays.
- Rename existing usernames to the normalised form. Cleaner data, but it would silently change how existing parents log in. Matching all common spellings avoids touching them.
Follow-ups¶
- Show the outcome after admit: the login created, linked or skipped (and why), and the invite link when no email went out. The admit dialog drops this today.
- Merge duplicate parent logins within an organisation, after review.
- Registration form gaps from the research table: keep the parent's name when "not available", optional primary email with SMS invite, parent education for UDISE.
- Verify the cross-campus attendance read on staging. The test database runs as a superuser, so row-level security can't be proven in CI.