Access control

Separate operator, accountant and admin logins

Every principal asks the same question before handing the fee counter to a clerk: can they take money and print a receipt without quietly changing what a student owes? In Ilham 360 the answer is settled on the server, for every single request.

Admin, accountant, teacher and parent
4 roles

Admin, accountant, teacher and parent

Checked before the database is touched
Server-side

Checked before the database is touched

Disabling an account ends its live session
Instant

Disabling an account ends its live session

Accountant logins included
Starter up

Accountant logins included

Four roles, four different systems

Everyone signs in at the same address and what they get is decided by their role. Nobody is shown a menu full of things they cannot open.

What each role sees
RoleWhat they get
School adminEverything — students, staff, fees, exams, settings and user accounts
AccountantThe fee counter — payments, receipts, invoice runs and fee reports
TeacherTheir own classes — attendance, marks for their papers, homework, notices
ParentTheir own children — fees due, attendance, results, homework, notices

What the accountant can and cannot do

The accountant role is the one that matters for a fee office, and it is deliberately narrow. It writes to the fee module and nothing else. It reads students and classes, because a payment cannot be recorded without looking a student up and an invoice run cannot start without picking a class.

Accountant permissions
CanCannot
Record a paymentCreate or change a fee head
Issue and reprint a receiptChange a fee structure
Generate monthly invoicesEdit or delete a student
Apply a recorded discountMark attendance or enter exam marks
Run collection and defaulter reportsChange school settings
Export those reports to ExcelCreate or manage other users

Enforced on the server, not in the menu

Hiding a button is not access control. Every school-portal request in Ilham 360 is checked before it reaches the database: the token is verified, the role is checked against the module being asked for, the session is confirmed still live, and a write is refused where the role holds read access only.

An accountant cannot reach an admin screen by typing its address, and cannot call an admin endpoint directly either. A test in the codebase fails the build if anyone adds a school-admin route without one of those guards.

Every query is scoped to the school in the signed-in user’s own token, never to a school identifier sent by the browser, with row level security enabled on the database underneath as a second layer.

Adding and removing people

A school admin creates the accountant login from Settings and disables it the moment someone leaves. Disabling takes effect immediately — an open session stops working rather than running on until its token expires.

  • Accountant logins included from Starter upward
  • Disabling an account ends its live session at once
  • Teacher accounts created with a random password, never a shared default
  • Teacher and parent logins produced in bulk with printable credential slips
  • Password resets by email, or as a single-use link over WhatsApp
  • Passwords hashed with bcrypt, never stored or shown in the clear
  • Ten failed sign-ins lock an account for fifteen minutes

Common questions

Can a fee operator change what a student owes?

No. The accountant role can record payments, issue receipts, generate invoices and run fee reports. It cannot create or change a fee head, alter a fee structure, edit a student record or change a discount. Those stay with the school admin.

Is the restriction enforced properly, or just hidden in the menu?

Enforced on the server. Every school-portal request is checked before it touches the database: the token is verified, the role is checked against the module being requested, the session is confirmed live, and a write is refused where the role has read access only. Typing an admin address directly, or calling the endpoint directly, both fail.

What happens when a member of staff leaves?

A school admin disables the account and it stops working immediately — the live session ends rather than running on until the token expires.

Can one school see another school’s data?

No. Every query is scoped to the school in the signed-in user’s own token, never to anything the browser sends. Row level security is enabled on the database as a second layer.

Which plan includes an accountant login?

Accountant logins are included from Starter upward.

Try it on a real school, today

Your trial opens on a full Pakistani school — students, families, challans, results — already loaded. You are looking at working screens in under a minute, not an empty setup wizard.