User Types Table ( aka User Roles)

The new User Types table will separate the specific types of users on site out of the PHP code. Thus, any institution would be able to modify existing user types, and create new ones. Each user types will have customizable permissions to access different components of the site. The permissions will tell what each type 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 Types
• 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 type 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 Types	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 types.
• 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?