RFC: Unit Permission

[polowis]

Change Description

This RFC introduces a novel approach to managing permissions through the integration of a "Unit Permission" table within the database architecture. In our existing setup, users can have many roles, each potentially can have multiple of permissions. However, roles alone should suffice at the highest level of permission management. The permission can be safely removed from the initial design.

The inclusion of a "Unit Permission" table can give unit creators with the capability to make custom roles and permissions that are specific to their individual units. This adjustment is essential for delivering a meticulously organised, highly scalable, and remarkably flexible system.

Reason for change

The project requires a more granular and flexible permission system, allowing unit creators to define custom roles and permissions specific to their units. This change is driven by the need to provide unit creators with greater access control within their units, resulting in a more user-friendly and customisable experience.

Use case

Consider the scenario where a Unit Creator seeks to extend invitations to fellow teachers for participation in their unit. However, they have distinct preferences for the level of access granted to each teacher. These preferences encompass the desire to impose varying restrictions on their colleagues' actions within the unit. For instance, certain teachers may be confined to a restricted role that limits their ability to manage activities within the unit. Others may have access exclusively for viewing student submissions, while another group may be tasked with overseeing students' work and grading it.

This use case exemplifies the need for a flexible and granular permission system that can meet access requirements of different users within the educational context.

Proposed Change

Table unit_permisison:

• ID (Primary Key, Integer): A unique identifier for each permission.
• RoleID (String): The ID of a custom role defined by the unit creator.
• Permission (Integer): The custom permission associated with the role.
• Position: The position of the role that can override.
• CreatedAt (Timestamp): The date and time when the permission was created.

Table unit_role

• ID (Primary Key, Integer): A unique identifier for each permission.
• UnitID (Integer): The ID of the unit to which the permission applies.
• Name (String): The name of this role
• Visible (Boolean): We might want to display role name next to user name.

Permission
Permission bitwise flag:

Permission	Value	Description
MANAGE_GRADE	1 << 0	Allow to view all student submission, grade their submission including graded activities
MANAGE_ASSIGNMENT	1 << 1	Allow to create, edit and remove assignments
MANAGE_QUIZ	1 << 2	Allow to create, edit, remove quiz
MANAGE_USER	1 << 3	Allow to remove, add users, as well as assigning roles
MANAGE_RESOURCE	1 << 4	Allow to publish module, edit module and remove module
ADMINSTRATOR	1 << 5	All permission, override everything else

Impact assessment

• Database schema: A new table will be added.