User Roles
The new User Roles table would separate the specific roles of users on site out of the PHP code. Thus, any institution would be able to modify existing user roles, and create new ones. Each user role will have customizable permissions to access different components of the site. The permissions will tell what each role can do with each component.
iPeer Components
Following is a list of components that each user can potentially access. Each one maps to a database table, or a set of tables (ex. evaluation tools).
- System Parameters
- User Roles
- Users
- Groups
- Courses
- Evaluation Tools
- Events
- Messages
Permissions
The following permissions will describe the level of permissions for each component. The lower 4 bits of the number give the general permissions:
| 0.. No access at all. | The iPeer site will not show this tab to the user, and all related controller calls will be unavailable. |
| 4.. Read access. | User can search lists, view items, but cannot change them in any way. |
| 8.. Read-Write access. | User can search list, view items, and modify the items view. User can not create or delete items. |
| 12 Read-Write-Create-Delete | User can list, view items, can modify them, and can create or delete the items they wish. |
| 1,2,3,5,6,7,9,10,11,13,14,15 | ...are all Reserved for future use. Should map to the next lower valid value. |
The higher bits are reserved for flags.
+16) Can perform evaluations. This is how the system knows this person user role is a student. Flag(s) bellow relate to student permissions:
+32) Can list own group members & see some of their details (ex. names & email)
+64) Can see some details (ex names & email) of all students in the class. Must have at least Permission Level "Read" (>=4) for the Course.
Suggested Default Table Contents
| Short Char | Privilige Level | Sys.Params | User Role | Users | Groups | Courses | Evaluation Tools | Events | Messages | |
| Super Admin | S | 1200 | R-W + C-D | R-W + C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D |
| Faculty Admin | F | 1000 | R | R-W + C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D | R-W & C-D |
| Course Coordinator | C | 800 | R | R-W & C-D | R-W & C-D | R-W | R-W & C-D | R-W & C-D | R-W & C-D | |
| Instructor | I | 600 | R | R-W & C-D | R-W & C-D | R | R-W & C-D | R-W & C-D | R-W & C-D | |
| T.A. | T | 400 | R-W & C-D | R-W & C-D | R | R-W & C-D | R-W | R | ||
| Student | S | 200 | +16 | R | R |
Legend:
- R-W + C-D - Read & Write & Create & Delete (12)
- R-W - Read & Write Only (8)
- R - Read Only (4)
- No label - No permissions (0)
Suggested System-wide permissions
- Users can view their own details/profile, even if they have no User Read permission.
- If a user is assigned to an item (course, etc...) they should be able to view some of its details.
- Ex: All users can always list the courses they are assigned to. They can also view the courses' details, but not the whole class list.
- One can not write any course, unless they are enrolled in it & have write permissions (R-W); or if they can create courses (R-W & C-D), regardless of enrollment.
- Only users of lower privilege levels can be created. No equal's creation is allowed. Same goes for user roles.
- A user can view/modify another user, given that the target user is bellow this user's privilege level.
Thoughts for Discussion
- Events, Evaluations, Groups, Messages should only be listed for the enrolled course, for all users except Admins. Does this table need to be modified to accommodate this? If so, in what way?
- If we're going UBC-wide, should we implement Faculties as a component?
- Should we implement course sections?
- Should we implement course terms, so that the database keeps a record of all the previous terms and courses?
