Model actions, records and context
A role label by itself is not a complete permission rule. Define the action, the record and the context. A teacher may be allowed to enter attendance for an assigned class but not edit fee records. A parent may see their own child's information but not another family's details.
Write these rules in a matrix and review exceptions explicitly. Staff moving between classes or schools, guardians with several children and finance-specific responsibilities can change the context without changing the basic role name.
Keep the school boundary explicit
In a multi-school application, identifying a logged-in user is only the first step. Every request also needs an authorised school context. Selecting a school in the interface should not be sufficient to grant access to its records.
The backend should validate access to the requested operation and data. Hiding a menu item is useful interface design, but it does not protect an endpoint that still accepts the request. Default-deny behaviour and server-side authorisation are established access-control principles.
Test the requests that must fail
A permission test plan should include attempts to access another school, another student's record and an operation reserved for a different responsibility. Test read, write, export and background-processing paths; permission rules can be lost where data leaves the main screen.
- Parent A cannot read Parent B's child record
- A teacher cannot edit financial records without an explicitly granted responsibility
- A school-specific export cannot include another school's records
- Changing an identifier in a request does not change the user's authority
- Revoked access stops working in the applicable sessions and workflows
Document assumptions and review change
This is an architectural checklist, not an audit of AogsiERP or a guarantee of security. A working implementation needs code review and tests against the actual data model. Log relevant administrative changes without exposing sensitive student data in general application logs.
The useful deliverable is a permission matrix tied to acceptance tests. That gives product, design and development a shared way to discuss access changes before they become inconsistent screens and endpoints.