Why your LMS is really a permissions problem
An admin, a teacher and a student look at the same attendance record and are each allowed to do something different with it. Get that wrong and no feature list saves you.
By Shashi Kumar ·
I have built two learning management systems now — one for schools, one adapted for coaching institutes. Both taught me the same thing: education software is a permissions problem wearing a feature list.
The same record, three truths
Take one attendance entry. Student X, absent, 14 March.
- The student may see it. They may not change it. They may be able to request a correction.
- The teacher may see it, may change it today, and may not change it after the term closes.
- The administrator may change it any time, but the change must leave a trace, because attendance is a legal record in a way most software people forget.
That is one row of one table with three different behaviours attached. Multiply by every entity in the system — grades, fees, assignments, reports — and you can see where these projects actually go wrong.
The failure mode: permissions in the UI
The tempting shortcut is to hide the button. The teacher does not see an "edit" control after term close, so the problem is solved.
It is not solved. It is hidden. The API still accepts the request. Anyone with the endpoint — a stale browser tab, a mobile client, a curious student with developer tools — can still do it.
Permissions belong at the data layer. The UI hides the button as a courtesy. The server refuses the write as the actual rule. If those two ever disagree, the server is right and the UI is a bug.
What that looks like in practice
Every query carries the actor, not just the arguments. Not getAttendance(classId) but getAttendance(classId, actor), where the actor's role shapes what comes back and what may be written.
This is more verbose. It is also the only version that survives a second client.
The bit nobody scopes: the audit trail
Every education system eventually needs to answer "who changed this grade, and when?" — usually urgently, usually because someone is upset.
If you did not build that in from the start, you cannot retrofit it for historical data. The information is simply gone. I now treat an append-only change log on grades, attendance and fees as a requirement, not a nice-to-have, and I say so in the first conversation.
Where school and coaching diverge
The school system and the coaching system share an engine, and I would do that again — but the domains genuinely differ:
- Schools run on terms and fixed classes. Coaching institutes run rolling batches with students joining mid-cycle.
- Schools assess periodically. Coaching institutes run repeated test series where the trend matters more than any single score.
- Schools collect fees annually. Coaching institutes collect monthly, and the fee cycle determines whether the business survives the quarter.
Generalising the model to cover both was the right call. Forcing them into identical workflows would not have been. Share the engine, respect the difference.
If you are commissioning one of these
Ask the vendor how permissions are enforced. If the answer describes screens, keep looking. If it describes the data layer, you are talking to someone who has done this before.
Contact Acquiretech Software Solution: info@acquiretechsoftwaresolution.in · WhatsApp +91 80786 33912 · Send an enquiry