Fully customisable user permissions and profiles - Kosudo/nextSIS GitHub Wiki

It is typical for a SIS to offer four levels of access:

• Administrator
• Teacher
• Parent
• Student

Pre-defined profiles/roles can be problematic however. For example, if you restrict a teacher to only seeing their own class, they can't take attendance for a class they are covering on a particular day, and some teachers don't teach specific classes but do need access to student records.

At the administrator level, there is a case for allowing management and office staff the ability to undertake tasks such as creating courses - a typical admin function, but not the ability to create users.

What this means is nextSIS should support the following default roles:

• System Administrator
• Administrator
• General Teacher
• Class Teacher
• Parent
• Student

Our System Administrator is typically - though not necessarily - one person, who is the central point of contact and day-to-day controller of the SIS. An Administrator has the ability to conduct most administration tasks though not all (such as user creation and annual roll-overs) by default. A General Teacher can see all students in the school but can't conduct administrative tasks, whereas a Class Teacher can only see the records of students in the classes that they teach.

This leaves our remaining two profiles, which are fairly standard. A Parent user can see the records for their children, and a Student user can only see their own individual record.

Customisation

While it is all very well to set standard roles, it should be possible to fully customise the permissions of any user within the system, so this will involve the use of a full permissions table within the database and per-function authorisation checking, rather than a more simplistic system such as the use of a foreign key attached to a standard profile.