Report Cards in TouteGestion: Generation, Completion, Approval and Publication
Report cards are downstream records, not another place to type marks. TouteGestion generates them from the academic results already produced by the assessment workflow, checks whether required subject results are complete, allows controlled comments while the card is draft, then separates approval from final publication and issued-PDF evidence.
What a report card represents
A report card is a term-level presentation of a student's calculated academic record. Generation requires report_cards.generate permission and a student, term and class. The same generation engine can be run for one student or across active class members who do not yet have a report card for the term.
1. Generate from existing academic results
TouteGestion calls the report-card generation engine using the student, term, class and school. Bulk generation checks active class memberships and skips students who already have a report card instead of creating duplicates.
2. Treat completeness as a control
Report cards carry is_complete. Bulk approval explicitly skips an incomplete draft and reports the reason as a missing submitted result for a compulsory subject. This connects report-card readiness to the upstream result-submission workflow rather than allowing presentation to conceal missing academic evidence.
3. Add comments while the card is draft
Users with report_cards.generate can maintain class-teacher, headteacher and housemaster comments plus promotion decision, but updates are restricted to report cards still in draft status.
4. Use comment templates as assistance, not academic evidence
The product supports school-specific comment templates for class teacher, headteacher and housemaster categories. Standard starter templates can be loaded. Auto-fill chooses a template using overall average and fills only empty draft comment fields; housemaster comments are only considered where the student has a current hostel.
5. Approve only complete drafts
Approval requires report_cards.approve. A single card moves from draft to approved only when is_complete is true, recording approved_by and approved_at. Bulk approval applies the same completeness rule and records audit events for successful approvals.
6. Publish approved cards through issuance
Publication requires report_cards.publish and uses the report-card issuance service rather than merely changing a display flag. Bulk publication targets approved cards. Successful issuance returns an issued PDF storage key and SHA-256 hash, and the publication audit event records those values.
7. Keep generation, approval and publication distinct
Generation creates the report-card record from academic results; approval confirms a complete draft; publication issues the approved card. Separate permissions for generation, approval and publication allow a school to keep these responsibilities together in a small operation or separate them as governance becomes stricter.
Worked example
Primary 5 has 28 active students. Staff generate missing cards after teachers submit subject results. Two cards remain incomplete because a compulsory subject result is missing, so bulk approval skips those two and identifies the reason. Complete cards are reviewed, comments added and approved. A user with publish permission then issues the approved cards, leaving auditable PDF keys and hashes for the published documents.
Practical configuration checklist
- subject assessments published
- calculated subject results reviewed
- required subject results submitted
- active class membership correct
- report cards generated once per student/term
- incomplete cards investigated
- comments reviewed while draft
- approval permission assigned appropriately
- only complete drafts approved
- publication permission assigned appropriately
- issued PDF evidence retained
- approval/publication audit trail retained
Connect admissions, students, academics and school operations.
Explore the School product or continue through the School Knowledge Centre.