Lewati ke isi

Audit Implementasi Tugas, Ulangan/Ujian, Penilaian, dan eRaport

Audit tanggal: 2026-04-20
Mode kerja: server
Workspace root: /home/scola/odoo
Dokumen wajib yang dibaca sebelum audit: - scola-fe-v2/docs/ai-guidelines/development-guide.md - scola-fe-v2/docs/ai-guidelines/workspace-governance.md - scola-fe-v2/docs/ai-guidelines/architecture-api.md - scola-fe-v2/docs/qa/testing-guidelines.md

1. Ringkasan Eksekutif

Implementasi saat ini sudah mencakup surface utama untuk tugas, ulangan/ujian, penilaian, dan eRaport di hampir semua role inti sekolah: admin, teacher, homeroom, student, parent, principal, dan vice principal curriculum. Secara fungsional, sistem sudah cukup matang untuk operasi harian: guru dapat membuat tugas dan ujian, siswa dapat mengerjakan, gradebook guru menggabungkan hasil LMS + CBT, wali kelas memiliki workspace orkestrasi rapor, principal memiliki dashboard hasil ujian dan rapor, dan parent/student hanya melihat rapor terbit.

Namun ada gap governance yang signifikan terhadap best practice manajemen sekolah di Indonesia:

  1. Boundary RBAC belum konsisten antara frontend route, capability wildcard, controller, dan ACL Odoo.
  2. Workflow final eRaport tidak konsisten antara UI principal, state machine backend, dan hak publish admin.
  3. Kerahasiaan ujian CBT masih lemah pada endpoint baca detail/list.
  4. Artefak PDF parent belum memenuhi standar dokumen resmi sekolah karena dibuat di browser, bukan diterbitkan server.
  5. Model KKTP masih kuantitatif murni, sementara praktik Kurikulum Merdeka terbaru menekankan kemajuan belajar dan tidak lagi menjadikan KKM angka sebagai basis utama.

2. Metodologi Audit

Audit ini membandingkan tiga lapis implementasi:

  1. Frontend routing + page surface
  2. Frontend capability / role boundary
  3. Backend controller + ACL + record rule + workflow model

Area kode yang dipetakan:

  • Frontend route:
  • src/router/teacherRouteFragments/assessment.js
  • src/router/teacherRouteFragments/lmsAnalytics.js
  • src/router/teacherRouteFragments/homeroomSupport.js
  • src/router/studentRouteFragments/learning.js
  • src/router/parentRouteFragments/academic.js
  • src/router/principalRoutes.js
  • src/router/vicePrincipalRoutes.js
  • src/router/routerGuardPolicy.js
  • Frontend capability:
  • src/config/roleFragments/adminPlatformRoles.js
  • src/config/roleFragments/operationalRoles.js
  • src/config/roleFragments/portalRoles.js
  • src/config/roleFragments/executiveRoles.js
  • src/config/roleCapabilities.js
  • Backend:
  • custom_addons_scola/gcgscola/scola_lms/*
  • custom_addons_scola/gcgscola/scola_cbt/*
  • custom_addons_scola/gcgscola/scola_report_card/*
  • custom_addons_scola/gcgscola/scola_leadership_hub/*

3. Benchmark Best Practice Indonesia

3.1 Acuan resmi yang dipakai

Acuan Poin yang relevan
Pengembangan Kurikulum - Standar Penilaian Pendidikan Penilaian harus berkeadilan, objektif, edukatif; ada penilaian formatif dan sumatif; hasil belajar dituangkan dalam laporan kemajuan belajar/rapor.
FAQ Kurikulum Merdeka - KKM tidak lagi menjadi basis kuantitatif Ketuntasan hasil belajar tidak lagi diukur dengan KKM kuantitatif; fokus pada kemajuan belajar peserta didik.
Tahapan Implementasi Kurikulum Merdeka di Satuan Pendidikan Orang tua sebaiknya menerima informasi kurikulum/pembelajaran secara detail dan ada komunikasi dua arah dengan guru tentang perkembangan belajar anak.
Platform Pendukung Kurikulum Sistem digital pendidikan ideal mendukung integrasi data dan layanan pendukung implementasi kurikulum.

3.2 Implikasi best practice untuk audit ini

Catatan: poin di bawah adalah inferensi operasional dari acuan resmi di atas dan praktik umum manajemen sekolah Indonesia.

  • Tugas dan penilaian formatif harus berada dekat dengan proses belajar, cepat memberi umpan balik, dan terlihat jelas di gradebook guru.
  • Ulangan/ujian sumatif perlu boundary kerahasiaan lebih ketat daripada assignment biasa.
  • eRaport adalah artefak resmi sekolah, sehingga approval, publish, tanda tangan, QR, dan distribusinya harus konsisten dan auditable.
  • Principal dan vice principal curriculum idealnya berada pada layer oversight / approval / readiness monitoring, bukan ikut masuk ke workspace operasional guru kecuali memang diberi mandat eksplisit.
  • Parent idealnya menerima informasi progres belajar yang utuh dan konsisten, bukan hanya file unduhan di akhir semester.

4. Inventaris Halaman dan Cakupan Implementasi

4.1 Admin

Domain Halaman utama Status audit
Ujian / CBT config /admin/exam, /admin/examtype, /admin/examroom, /admin/examattendees, /admin/lms/settings di src/router/learningAssessmentRoutes.js:1-160 Ada
eRaport setup /admin/report-card/curriculum, /admin/report-card/grade-scale, /admin/report-card, /admin/report-card/:id, /admin/report-card/kktp, /admin/report-card/dapodik-sync di src/router/academicProgressRoutes.js:124-160 dan lanjutan file yang sama Ada
Publish final rapor Tombol publish ada di AdminReportList.vue:165-170 dan AdminReportDetail.vue:24-27 Ada

4.2 Teacher

Domain Halaman utama Status audit
Tugas /faculty/assignments, /faculty/assignments/create di src/router/teacherRouteFragments/assessment.js:1-22 Ada
Ulangan berbasis learning /faculty/assignments/exam-create di assessment.js:24-33 Ada
Bank soal CBT /faculty/question-bank* di assessment.js:53-98 Ada
Ujian CBT /faculty/cbt/exams, detail, analytics, item analysis, integrity report di assessment.js:100-178 Ada
Penilaian /faculty/assessment-hub, /faculty/report-card, /faculty/report-card/batch-input di assessment.js:35-50 Ada
Gradebook / LMS /faculty/lms, /faculty/lms/gradebook, /faculty/lms/analytics di src/router/teacherRouteFragments/lmsAnalytics.js Ada
Hasil ujian /faculty/exam-results/:examId di assessment.js:205+ Ada

4.3 Homeroom

Domain Halaman utama Status audit
Orkestrasi rapor kelas /faculty/homeroom/orchestrator, /faculty/homeroom/report-card, /faculty/homeroom/report-card/:reportId di homeroomSupport.js:1-19 Ada
Workflow submit / approve wali kelas Dijalankan dari HomeroomReportList.vue dan HomeroomReportDetail.vue Ada

4.4 Student

Domain Halaman utama Status audit
Tugas /student/assignment, detail di studentRouteFragments/learning.js:1-22 Ada
Ujian CBT /student/cbt, /student/cbt/runner/:exam_id di learning.js:46-54, 102-106 Ada
eRaport /student/report-card, /student/report-card/:reportId di learning.js:56-66 Ada
LMS /student/lms* di learning.js:68-120 Ada

4.5 Parent

Domain Halaman utama Status audit
Tugas /parent/assignment di parentRouteFragments/academic.js:8-16 Ada
Nilai ringkas anak /parent/grades di academic.js:50-55 Ada
eRaport /parent/report-cards di academic.js:62-69 Ada
Progress LMS anak /parent/lms/progress, detail course anak di academic.js:81-95 Ada
Halaman ujian khusus parent Tidak ada route khusus ujian/schedule/result Gap UX

4.6 Principal

Domain Halaman utama Status audit
Hasil ujian /principal/academics/exam-results di principalRoutes.js:55-64 Ada
Laporan rapor kelas /principal/academics/reports memakai PrincipalReports.vue Ada
Overview LMS/academic Route principal academic dan LMS tersedia di principalRoutes.js Ada

4.7 Vice Principal Curriculum

Domain Halaman utama Status audit
Quality gate akademik /vice-principal/curriculum/quality-gate di vicePrincipalRoutes.js:127-134 Ada
Workspace approval rapor tersendiri Tidak ada Gap fungsi / desain proses

5. Alur Kerja Aktual

5.1 Tugas / LMS

  1. Guru membuat assignment di AddAssignmentPage.vue.
  2. Siswa melihat daftar tugas di AssignmentNew.vue, submit tugas, dan histori submission ditarik.
  3. Guru menilai di AssignmentGradingPage.vue.
  4. Nilai masuk ke gradebook guru di Gradebook.vue.
  5. Parent melihat progres melalui ParentAcademic.vue dan ChildProgress.vue.

Observasi:

  • Ini adalah alur yang paling dekat dengan best practice pembelajaran formatif.
  • Gradebook guru sudah menghubungkan tugas dan hasil CBT ke komponen penilaian sekolah.

5.2 Ulangan / Ujian

  1. Guru membuat exam berbasis pembelajaran dari AddExamPage.vue.
  2. Exam dibuat dengan exam_context: "learning" dan bisa diberi grade_component_type, grade_component_weight, serta auto_publish_to_gradebook (AddExamPage.vue:577-602).
  3. Siswa mengerjakan di CBTRunner.vue.
  4. Guru mengelola detail, peserta, grading attempt, publish ke gradebook, dan export lewat CBTExamDetail.vue.
  5. Principal melihat agregat hasil lewat ExamResultsReport.vue.

Observasi:

  • Desain ini baik untuk memisahkan exam learning dari exam independent.
  • Kerahasiaan exam belum setara kebutuhan high-stakes assessment karena endpoint read memakai sudo() tanpa scoping ownership yang cukup.

5.3 Penilaian dan eRaport

  1. Guru mata pelajaran input/memutakhirkan nilai di TeacherReportLineList.vue.
  2. Wali kelas mengorkestrasi rapor kelas di HomeroomReportList.vue dan HomeroomReportDetail.vue.
  3. Workflow backend:
  4. submit
  5. approve_wk
  6. approve_ks
  7. publish
  8. reject
  9. draft di report_card_workflow_api.py:22-54.
  10. Model state machine backend mengharuskan:
  11. submitted -> wali_kelas
  12. wali_kelas -> kepala_sekolah
  13. kepala_sekolah -> published di student_report.py:380-415.
  14. Student dan parent hanya bisa melihat rapor published melalui domain backend report_card_api.py:284-303.

Observasi:

  • Boundary published-only untuk student/parent sudah benar.
  • Workflow di UI principal tidak sinkron dengan workflow backend.
  • Peran admin saat ini menjadi publisher final, bukan hanya operator/configuration.

6. Matriks RBAC Saat Ini

6.1 Frontend role/capability

Role Capability kunci Evidence
admin * dengan exclude students.*, parents.* adminPlatformRoles.js:1-5
teacher academics.assignments.manage, academics.lms.manage, academics.cbt_exams.manage, report_cards.records.manage operationalRoles.js:74-112
homeroom base teacher + students.homeroom.view operationalRoles.js:115-124
student academics.assignments.view, academics.lms.view, academics.cbt_exams.view, report_cards.list.view portalRoles.js:1-30
parent parents.children.view, academics.assignments.view, report_cards.list.view, analytics.family.view portalRoles.js:32-63
principal academics.exam_results.view, report_cards.list.view, academics.overview.view executiveRoles.js:1-53
vice_principal_curriculum academics.*, report_cards.* executiveRoles.js:68-79

6.2 Frontend route guard

Kontrol Evidence Catatan
isAdmin guard routerGuardPolicy.js:300-313 Baik untuk admin surface
allowedRoles guard routerGuardPolicy.js:315-329 Hanya aktif bila route memang mendeklarasikan allowedRoles
Capability guard routerGuardPolicy.js:345-362, accessContract.js:76-165 Wildcard capability aktif
Wildcard evaluator roleCapabilities.js:68-123 academics.* dan report_cards.* akan match route guru

6.3 Backend role/ACL highlights

Area Status Evidence
LMS teacher/student record rule Relatif baik scola_lms_security.xml:5-197
Student/parent published-only rapor Baik report_card_api.py:284-303
Principal read-only rapor ACL Baik scola_report_card/security/ir.model.access.csv:14-21
Wakasek curriculum CRUD op.exam Terlalu luas scola_cbt/security/ir.model.access.csv:52-53
CBT read controller pakai sudo() Risiko tinggi exam_read_api.py:15-58, 95-145

7. Gap Analysis Prioritas

A-01. Frontend teacher workspace belum dibatasi role secara konsisten

Severity: Critical

Evidence

  • teacherRoutes.js hanya menggabungkan fragment route guru tanpa scope role tambahan.
  • Route guru assessment/LMS/report card di teacherRouteFragments/assessment.js dan lmsAnalytics.js tidak mendeklarasikan allowedRoles.
  • Router hanya menolak role jika allowedRoles ada (routerGuardPolicy.js:315-329).
  • vice_principal_curriculum memiliki wildcard academics.* dan report_cards.* (executiveRoles.js:68-79).
  • Wildcard evaluator memang match capability route (roleCapabilities.js:68-123).

Dampak

  • Boundary /faculty/* bersifat capability-only, bukan workspace-only.
  • Role eksekutif tertentu dapat lolos guard frontend ke halaman operasional guru jika capability-nya match.
  • Ini minimal menyebabkan UX bocor; untuk beberapa endpoint CBT, bocornya bisa menjadi akses data nyata.

Gap terhadap best practice

  • Workspace guru idealnya dibatasi tegas untuk role operasional pengajar/homeroom, bukan sekadar berdasarkan wildcard capability.

Rekomendasi

  1. Terapkan scope mapper khusus /faculty dengan allowedRoles: ["teacher", "homeroom"] secara default.
  2. Tambahkan pengecualian eksplisit hanya untuk surface yang memang shared dengan role lain.
  3. Audit ulang seluruh route /faculty/* yang sekarang hanya capability-based.

A-02. Kerahasiaan ujian CBT lemah pada endpoint list/detail

Severity: Critical

Evidence

  • _check_access() di scola_cbt/controllers/exam.py:202-209 hanya memeriksa apakah user termasuk faculty-like / manager / proctor / back-office.
  • list_exams() memakai request.env['op.exam'].sudo() dan domain filter fungsional saja, tanpa scoping ke guru pemilik/subject/class (exam_read_api.py:15-58).
  • get_exam() juga memakai sudo().browse(exam_id) setelah hanya memanggil _check_access() (exam_read_api.py:95-145).
  • Payload detail memuat cbt_token, attendee list, schedule, dan metadata peserta (exam_read_api.py:127-152).

Dampak

  • Guru/proctor yang lolos _check_access() berpotensi membaca metadata exam lintas kelas.
  • Token CBT, daftar peserta, dan jadwal ujian bisa terekspos ke user yang tidak relevan.
  • Ini tidak sesuai untuk high-stakes exam governance.

Gap terhadap best practice

  • Ujian sumatif memerlukan prinsip least privilege, terutama untuk token, peserta, dan jadwal ujian.

Rekomendasi

  1. Hapus sudo() pada list/detail atau batasi dengan domain yang benar-benar mengikat ke ownership/assignment/proctor assignment.
  2. Pisahkan hak view own exam, view proctored exam, dan view schoolwide exam analytics.
  3. Jangan kembalikan cbt_token di list/detail umum; pindahkan ke endpoint khusus manage/proctor.

A-03. Workflow final eRaport tidak sinkron antara UI principal, backend state machine, dan admin publish

Severity: Critical

Evidence

  • Backend mengharuskan wali_kelas -> kepala_sekolah -> published (student_report.py:389-415).
  • Controller workflow juga memisahkan approve_ks dan publish (report_card_workflow_api.py:24-31).
  • UI principal hanya menampilkan tombol approve jika student.status === 'kepala_sekolah' (PrincipalReports.vue:264-270).
  • Dialog principal menyatakan “Raport akan dipublikasikan” dengan tombol Approve & Publish (PrincipalReports.vue:326-337).
  • Handler principal justru memanggil APPROVE_KS (PrincipalReports.vue:670-679), bukan PUBLISH.
  • Sementara admin justru memiliki tombol publish di AdminReportList.vue:165-170 dan AdminReportDetail.vue:24-27.
  • Data status yang dipakai principal dikirim mentah dari backend sebagai report.state (executive_academic_api.py:497-528).

Dampak

  • Principal UI tidak mewakili state machine yang sebenarnya.
  • Ada split governance: principal terlihat seperti publisher, tetapi admin yang benar-benar publish.
  • Potensi salah keputusan operasional tinggi pada masa penutupan rapor.

Gap terhadap best practice

  • Dokumen resmi rapor harus punya alur otorisasi yang tunggal, jelas, dan konsisten di semua layar.

Rekomendasi

  1. Tentukan model final yang tegas:
  2. Opsi A: homeroom -> vice principal curriculum -> principal -> publish
  3. Opsi B: teacher -> homeroom -> principal -> publish by principal
  4. Samakan naming/action/button di semua UI dengan state machine backend.
  5. Jika admin hanya operator, cabut aksi publish final dari admin surface.

A-04. Wakasek curriculum memiliki CRUD backend terlalu luas untuk op.exam

Severity: High

Evidence

  • scola_cbt/security/ir.model.access.csv:52-53 memberi scola_core.group_scola_vice_principal_curriculum hak read,write,create,unlink ke openeducat_exam.model_op_exam.

Dampak

  • Role monitoring/quality gate berubah menjadi role operasional penuh di backend.
  • Risiko perubahan exam tanpa jejak proses yang sesuai mandat wakasek.

Gap terhadap best practice

  • Wakasek kurikulum idealnya mengawasi kesiapan, mutu, dan approval, bukan memiliki hak CRUD default atas semua ujian.

Rekomendasi

  1. Turunkan ke read saja untuk default ACL.
  2. Tambahkan endpoint approval/readiness khusus jika wakasek memang harus memberi clearance.
  3. Pisahkan role exam governance reviewer dari exam operator.

A-05. Otorisasi setup report card drift antara FE, controller, dan ACL Odoo

Severity: High

Evidence

  • Semua route setup rapor di frontend bersifat isAdmin (academicProgressRoutes.js:124-160 dan route setup lain di file yang sama).
  • _can_manage_setup() hanya mengizinkan role admin (report_card_api.py:391-392).
  • Tetapi group_report_card_manager diberi CRUD penuh pada curriculum, assessment component, dan grade scale di scola_report_card/security/ir.model.access.csv:2-9.
  • kktp_save() memakai whitelist role string yang berbeda: admin, admin_staff, staff, administrator, super admin (report_card_setup_scale_api.py:228-233).
  • kktp_list() tidak punya role guard eksplisit sebelum mengembalikan seluruh konfigurasi (report_card_setup_scale_api.py:185-226).
  • Parent bahkan punya read ACL ke curriculum, assessment component, grade scale, grade scale line (ir.model.access.csv:33-39).

Dampak

  • Sulit memastikan siapa yang benar-benar berhak mengelola setup akademik.
  • Potensi bypass lewat endpoint atau RPC lain meningkat.
  • Audit akses menjadi sulit dipertanggungjawabkan.

Gap terhadap best practice

  • Setup akademik dan setup rapor harus memiliki satu matriks otorisasi yang konsisten lintas FE, API, dan model.

Rekomendasi

  1. Tetapkan satu SSOT role untuk setup rapor, mis. admin + report_card_manager bila memang dibutuhkan.
  2. Samakan guard route, controller, dan ACL CSV.
  3. Tambahkan guard eksplisit untuk endpoint kktp/list.
  4. Cabut read setup dari parent kecuali benar-benar ada use case resmi.

A-06. PDF eRaport parent masih client-generated, belum menjadi artefak resmi sekolah

Severity: High

Evidence

  • Tombol unduh parent ada di raportList.vue:75-80.
  • Handler memanggil fetchParentReportPdfPayload() lalu generateRaportPDF(payload) di browser (raportList.vue:294-297).
  • Service hanya menggabungkan payload JSON + school info (parentReportCard.service.js:139-145).
  • Utility PDF membuat tanggal memakai new Date() browser lokal dan menggambar area tanda tangan secara statis (pdfRaport.js:397-430).

Dampak

  • Dokumen dapat berbeda tergantung timezone/browser/device.
  • Sulit menjadikan file hasil unduh sebagai dokumen resmi yang immutable.
  • QR/tanda tangan/headmaster info tidak dijaga sebagai server-issued artifact.

Gap terhadap best practice

  • eRaport yang dibagikan ke parent sebaiknya diterbitkan server-side, punya metadata penerbitan, dan jejak audit yang stabil.

Rekomendasi

  1. Pindahkan generasi PDF ke backend.
  2. Simpan hash/file metadata per publikasi.
  3. Gunakan published_at, signer, QR verification, dan school timezone dari server.

A-07. Principal reject flow tidak memaksa atau menampung alasan penolakan

Severity: High

Evidence

  • Backend workflow menerima reason untuk reject (report_card_workflow_api.py:44-50).
  • Dialog principal hanya confirm sederhana tanpa input alasan (PrincipalReports.vue:340-350).
  • Handler reject principal tidak mengirim reason (PrincipalReports.vue:692-701).

Dampak

  • Penolakan rapor kehilangan konteks perbaikan.
  • Audit trail keputusan menjadi lemah.
  • Homeroom/guru menerima reject tanpa catatan koreksi yang jelas.

Gap terhadap best practice

  • Approval governance sekolah seharusnya menyertakan alasan ketika dokumen akademik ditolak.

Rekomendasi

  1. Jadikan reason wajib pada action reject.
  2. Tampilkan histori alasan di detail rapor.
  3. Masukkan alasan ke notifikasi homeroom/guru dan audit log.

A-08. Model KKTP masih kuantitatif murni dan terlalu dekat ke paradigma KKM lama

Severity: High

Evidence

  • Model scola.subject.kktp menyimpan kktp_value angka 0..100 dan menjadikan nilai di bawah threshold otomatis remedial (subject_kktp.py:31-38, 55-61).
  • Curriculum menyimpan default_kktp angka (curriculum.py:65-73).
  • Report line meng-auto-flag remedial berdasarkan threshold numeric (student_report.py:765-772).
  • UI admin KKTP juga hanya menyediakan input angka (KKTPConfig.vue:55-64, 107-114).
  • Acuan resmi terbaru menyatakan ketuntasan hasil belajar tidak lagi diukur dengan KKM kuantitatif semata (FAQ Kurikulum Merdeka).

Dampak

  • Sistem mendorong keputusan remedial berbasis threshold tunggal, padahal praktik Kurikulum Merdeka menuntut fokus pada progres dan deskripsi capaian.
  • Sekolah yang ingin rubrik/descriptor-based mastery akan mentok di model saat ini.

Gap terhadap best practice

  • KKTP sebaiknya mendukung minimal dua mode:
  • numeric threshold untuk sekolah yang masih butuh transisi
  • deskriptif/rubrik/progress band untuk implementasi Kurikulum Merdeka yang lebih matang

Rekomendasi

  1. Tambahkan policy mode numeric vs descriptor.
  2. Pisahkan remedial policy dari sekadar threshold angka.
  3. Kaitkan dengan deskripsi capaian pada report line.

A-09. Masih ada jalur assessment yang memakai Odoo JSON-RPC mentah

Severity: Medium

Evidence

  • AssignmentGradingPage.vue masih memanggil /web/dataset/call_kw/lms.course.item/web_search_read (AssignmentGradingPage.vue:648-679).
  • AssignmentNew.vue masih memanggil /web/dataset/call_kw/lms.submission/search_read (AssignmentNew.vue:389-407).
  • Ini bertentangan dengan arah same-origin API architecture pada architecture-api.md yang menekankan endpoint domain eksplisit.

Dampak

  • Rule dan observability mudah drift antara route modern /api/* dan jalur RPC lama.
  • Audit RBAC menjadi lebih sulit karena sebagian akses lewat model action Odoo, bukan kontrak domain.

Gap terhadap best practice

  • Fitur akademik inti seharusnya memakai domain endpoint eksplisit agar mudah di-hardening dan diaudit.

Rekomendasi

  1. Migrasikan assignment detail/submission query ke /api/lms/*.
  2. Tutup jalur RPC lama dari FE untuk flow siswa/guru yang sudah punya service domain.

A-10. UX parent untuk penilaian masih terfragmentasi

Severity: Medium

Evidence

  • Parent memiliki route terpisah untuk assignment (/parent/assignment), nilai ringkas (/parent/grades), rapor (/parent/report-cards), dan LMS progress (/parent/lms/progress) di parentRouteFragments/academic.js:1-96.
  • Tidak ada halaman khusus yang menyatukan status tugas, hasil ulangan, tren nilai, dan status rapor per anak.

Dampak

  • Orang tua perlu berpindah beberapa halaman untuk memahami progres akademik anak.
  • Ini belum sepenuhnya selaras dengan praktik komunikasi dua arah dan informasi progres yang detail ke orang tua.

Gap terhadap best practice

  • Parent portal idealnya memberi satu academic progress hub per anak, bukan sekadar kumpulan halaman terpisah.

Rekomendasi

  1. Buat Parent Academic Hub yang menggabungkan assignment due, hasil sumatif, tren grade, dan status rapor.
  2. Tambahkan indikator needs attention dan notifikasi ketika ada penurunan performa atau rapor ditolak/revisi.

8. Hal yang Sudah Kuat

  1. Student dan parent hanya bisa melihat rapor published dari backend, bukan draft/submitted (report_card_api.py:284-303).
  2. LMS memiliki record rule yang relatif rapi untuk faculty dan student (scola_lms_security.xml:5-197).
  3. Gradebook guru sudah mendukung pemetaan hasil tugas dan exam ke komponen penilaian sekolah.
  4. Surface CurriculumQualityGate.vue untuk vice principal curriculum adalah fondasi oversight yang baik.
  5. Frontend principal dan vice principal sudah memakai scoped route metadata, berbeda dengan teacher workspace yang masih longgar (principalRoutes.js:1-12, vicePrincipalRoutes.js:14-67).

9. Rekomendasi Prioritas

0-30 hari

  1. Kunci role boundary /faculty/* dengan scope role eksplisit.
  2. Hardening endpoint CBT list/detail agar tidak memakai sudo() tanpa domain ownership.
  3. Benahi workflow principal/admin publish eRaport agar satu sumber kebenaran.
  4. Wajibkan alasan penolakan rapor.

30-60 hari

  1. Satukan matriks otorisasi setup rapor lintas FE/API/ACL.
  2. Pindahkan PDF eRaport parent ke server-side generation.
  3. Kurangi akses CRUD wakasek curriculum atas op.exam.
  4. Migrasikan sisa flow assessment dari JSON-RPC mentah ke /api/*.

60-90 hari

  1. Redesign model KKTP menuju mode numeric + descriptor.
  2. Tambah Parent Academic Hub.
  3. Tambah approval inbox lintas peran untuk principal/vice principal curriculum.

10. Kesimpulan

Secara produk, modul ini sudah melewati tahap “belum ada” dan sudah masuk tahap “operasional tetapi perlu hardening governance”. Gap terbesarnya bukan ketiadaan halaman, melainkan konsistensi otorisasi, konsistensi workflow otorisasi dokumen resmi, dan kualitas artefak resmi untuk parent.

Jika targetnya adalah best practice sekolah Indonesia yang siap diaudit dan aman dipakai lintas semester, backlog yang paling mendesak adalah:

  1. RBAC hardening
  2. workflow eRaport canonicalization
  3. CBT confidentiality hardening
  4. server-issued report artifact