Ifitwala Logo Ifitwala Ed

Applicant Document Type: Authoritative Admissions Evidence Catalog

Define canonical admissions document types and codes that drive portal options, readiness checks, and deterministic file-classification slots.

On this page

Before You Start (Prerequisites)

  • Create Organization first, and School if you need school-scoped types.
  • Define stable code values before go-live; autoname is field:code.
  • Ensure each code is mapped in admissions slot classification logic (APPLICANT_DOCUMENT_SLOT_MAP), or upload will be rejected.

Applicant Document Type is the canonical admissions evidence catalog. It defines what document slots exist and which of those slots are required in readiness checks.

Authoritative Contract

Applicant Document Type controls admissions document semantics, not file ownership:

  • semantic fields (code, document_type_name, belongs_to, description)
  • scope fields (organization, school)
  • gating fields (is_required, is_active)

belongs_to is semantic only (student | guardian | family) and does not change the rule that admissions files are owned by Applicant Document.

Non-Negotiable Invariants

  1. code is unique and acts as the canonical identity for the type.
  2. Required-readiness contract is driven by active types where is_required = 1 and scope matches applicant organization/school.
  3. Portal upload options must be limited to active, in-scope types.
  4. Slot derivation and classification use code (deterministic), not label text.
  5. Type deactivation (is_active = 0) retires future use without rewriting historical applicant evidence.

Where It Is Used Across the ERP

  • Applicant Document: each row references one type.
  • Student Applicant: readiness check resolves required types by org/school scope.
  • Admissions portal:
    • list_applicant_document_types
    • upload_applicant_document pre-validation for activity and scope
  • Governed upload routing:
    • Applicant Document Type.code -> slot mapping in APPLICANT_DOCUMENT_SLOT_MAP
    • unmapped codes are rejected by admissions upload service
Code is infrastructure

Changing code is not a cosmetic rename. It affects slot derivation and classification paths in governed admissions upload.

Operational Guardrails

Do

  • Use stable, deterministic code values and treat them as long-lived contract identifiers.

  • Scope types by organization/school only when there is a real policy difference.

Don't

  • Use belongs_to as a permission or ownership switch; it is semantic metadata only.

  • Deactivate by deleting historical meaning; prefer is_active = 0 for retirement.

Lifecycle and Governance Flow

Applicant Document Type Governance
1

Define Catalog

Create the evidence catalog with canonical code and document_type_name values.

2

Set Scope and Requirements

Configure organization, optional school, and requirement flags (is_required, is_active).

3

Publish to Portal Behavior

Portal document type listing returns only active and applicant-scoped types.

4

Drive Readiness

Student Applicant readiness treats required types as satisfied only when a corresponding Applicant Document is approved.

5

Evolve Safely

Retire obsolete types with is_active = 0 and introduce new codes instead of mutating historical contract semantics.

Reporting

  • No dedicated Script/Query Report currently uses this doctype as ref_doctype.
Related Admissions Catalog and Evidence Docs

Applicant Document: Governed Admission File Record

->
Admission

Track each applicant document type, review status, and promotion relevance with strict immutability and governed file handling.

Student Applicant: The Admission Record of Truth

->
Admission

Manage applicant lifecycle from invitation to promotion, with readiness checks, governed files, policy acknowledgements, and portal access.

Applicant Health Profile: Health Disclosure and Clearance

->
Admission

Capture health details, control family/staff editing by applicant status, and feed readiness for admissions decisions.

Inquiry: Managing First Contact with Prospective Families

->
Admission

Capture, assign, and track inquiry follow-up with SLA visibility, assignment ownership, and conversion into Student Applicant.

Technical Notes (IT)

Latest Technical Snapshot (2026-02-22)

  • DocType schema file: ifitwala_ed/admission/doctype/applicant_document_type/applicant_document_type.json

  • Controller file: ifitwala_ed/admission/doctype/applicant_document_type/applicant_document_type.py

  • Required fields (reqd=1):

    • code (Data, unique)
    • document_type_name (Data)

  • Lifecycle hooks in controller: none (controller is currently pass).

  • Operational/public methods: none beyond standard document behavior.

  • DocType: Applicant Document Type (ifitwala_ed/admission/doctype/applicant_document_type/)

  • Autoname: field:code

  • Core field contract:

    • belongs_to options: student, guardian, family
    • is_required default 0
    • is_active default 1
    • optional scope: organization, school

  • Portal/API surfaces:

    • list endpoint: ifitwala_ed/api/admissions_portal.py::list_applicant_document_types
    • upload pre-validation path: ifitwala_ed/api/admissions_portal.py::upload_applicant_document
    • governed upload implementation: ifitwala_ed/admission/admissions_portal.py::upload_applicant_document
    • SPA consumer: ifitwala_ed/ui-spa/src/pages/admissions/ApplicantDocuments.vue

  • Downstream gating use:

    • required-document readiness in ifitwala_ed/admission/doctype/student_applicant/student_applicant.py::has_required_documents
    • slot/classification mapping by code in ifitwala_ed/admission/admission_utils.py::APPLICANT_DOCUMENT_SLOT_MAP

Permission Matrix

Role Read Write Create Delete Notes
Admission Officer Yes Yes Yes Yes Full Desk access
Admission Manager Yes Yes Yes Yes Full Desk access
Academic Admin Yes Yes Yes Yes Full Desk access
System Manager Yes Yes Yes Yes Full Desk access