Student Enrollment & Progress Tracking (Education)

Paid pluginsize Lplanned, not built

Indicative price, not an offer: €54/mo; 500 students included, support for grades & attendance

Generated from docs/plan/paid/student-enrollment-progress-tracking/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid module for education institutions to track student enrollments, tuition fees, academic progress, and generate GDPR-compliant progress reports for parents. Core provides multi-contact management and order history; this pack adds cohort management, grade tracking, progress rollup logic, and a parent portal with selective data access.

The problem

Schools managing 50+ students manually track enrollment in spreadsheets and email grade updates to parents. They lose audit trails when disputes arise (‘was payment made?’, ‘when was the grade recorded?’), cannot legally prove they handle student data according to GDPR, and have no way to analyze cohort progression without manual calculation.

What it does

• Create Student entity with cohort/class associations, linked to core Contacts
• Track per-student tuition fees (currency-locked at invoice), late-payment compliance flags
• Store academic progress: grades, attendance scores, behavioral notes with audit timestamps
• Generate GDPR-compliant progress reports (parent-visible subset only) as PDF/email
• Parent portal: authenticated, role-gated view of own child’s progress, grades, fees
• Cohort analytics: track class-level pass rates, average grade by subject, attendance trends
• Trigger automated emails for grade milestones (high achievement, warning flags)
• Audit log every record write: who changed grades, when, previous value (education authority compliance)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Report card template design—schools provide their own branding (schools vary too widely; we provide data structure, not design)
• Integration with national education registries—credential/per-country obligation, owned by paid support team
• Predictive intervention logic (early warning systems)—requires ML/analytics expertise outside scope; schools build via custom reports
• Parent-teacher messaging—owned by a separate communications module; no 1:1 messaging here
• Synchronization with national exam systems—credential requirement (Abitur, GCSE, etc.), paid support-led feature
• Transcript generation for university admissions—per-country legal format; owned by consulting tier, not automation

Data model

New entities: Student (id, schoolId, firstName, lastName, cohort, enrolledAt, tuitionFeeMinorUnits, currency, status); Progress (id, studentId, type[grade|attendance|note], value, subject, recordedBy, recordedAt, changedAt, previousValue). Links: Student.contactId → Contact. Migration required: schools adding this feature for the first time must backfill enrollments from Contact records.

API

• POST /api/v1/students — create student (requires school admin role)
• GET /api/v1/students/{id} — fetch one student + progress timeline (parent can read own child only)
• PATCH /api/v1/students/{id} — update student cohort/fees (staff only)
• POST /api/v1/students/{id}/progress — record grade/attendance/note (staff only, audit logged)
• GET /api/v1/students/{id}/progress — list progress for student (parent/staff, filtered by role)
• GET /api/v1/cohorts/{cohortId}/analytics — class-level pass rates, average grade, attendance (staff only)
• POST /api/v1/students/{id}/progress-report — generate PDF progress report, optionally email

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Staff dashboard shows: student list (filter by cohort, enrollment status), individual student detail (grades, attendance, fees paid), progress entry form (grade/note/attendance), cohort analytics card (class pass rate, average GPA, attendance %), bulk email trigger for progress reports. Each school sees only their own students (multitenancy by schoolId).

The seam — why this is paid

Core owns: contact records, order history (for fee tracking), email infrastructure, audit logging, role/permission system. Paid pack owns: Student entity, Progress tracking entity, parent portal UI component, progress-report PDF generation, cohort analytics calculation. The seam is drawn here because schools legally must prove GDPR compliance and need ongoing support interpreting education authority regulations—core cannot guarantee that.

Support commitment: GDPR student data handling, progress reporting, parent portal SLA

Dependencies

• core:contacts — Student links to existing Contact records (parent/student contact info)
• core:orders — fee tracking uses order line items (tuition invoices, payment status)
• core:audit-log — every progress entry must audit-log who wrote it and when
• core:email — progress reports email to parents
• core:roles-and-permissions — parent role must be gated to read own child only
• core:multitenancy — each school is separate (schoolId isolation)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A student’s cohort and tuition fee are recorded when enrolled; fee currency locks to the shop’s setting at enrollment
• A grade recorded for a student (80/100, Math, 2026-01-15) appears in the student’s progress timeline with audit timestamp and staff member who recorded it
• A parent viewing their child’s progress sees only that child’s data; a parent cannot view another student’s grades
• A progress report PDF includes student name, grades by subject, average for cohort, attendance %, with a ‘generated on’ timestamp
• When a school updates a student’s grade (e.g., typo correction), the audit log records the previous value and timestamp of change
• A cohort analytics card shows class-level data: count of students, average grade, pass rate (grade >= 50), with a ‘last calculated’ timestamp
• An absent student (attendance < 80%) triggers an automated email to the parent with subject ‘Absence Alert: [Student Name]’
• A staff member without school admin role cannot update another school’s students (multitenancy boundary enforced)

Risks

Parents must not be able to forge authentication tokens to view other students—token payload validation must check parentOf[studentId]. Audit log corruption silently breaks education authority compliance; audit writes must be atomic and immutable. Cohort analytics calculations over 1000+ students could timeout; must batch or cache. Fee currency must never change after invoice—test retroactive currency edits fail.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.