[[PageOutline]] = Access Control = == Requirements == === User === * A user have at least one role in the system. * A user may have more than one role. (e.g. a person can be a TA and student) === Role === A role can be considered as a group of permission a user can have. There are some typical roles in iPeer: ==== Super Admin ==== * Have access to all the functions without restriction ==== !Faculty/School Admin ==== * Have the view of whole faculty and school * Can manage the instructors, students, courses, evaluations within the faculty/school ==== Instructor ==== * Have the view of his/her own courses, students, evaluations ==== Tutor ==== * Have the view of the courses he/she enrolled in ==== Student ==== * Have the view of the courses he/she enrolled in === Permission === The permission can give a user access to the resources. Although CakePHP default ACL can easily control the access to a specific controller/action. It is not enough for iPeer. Consider the following case: the admin and instructor roles both should have access to /user/add controller/action. Because admin should be able to add student and instructor and instructors should be able to add students to their course as well. However, instructor shouldn't have the ability to add admin. Therefore we consider two types of permissions iPeer. ==== !Controller/Action Permission ==== This type of permission controls if a role has access to a specific controller/action pair, E.g., Admin has access to /user/add or Student is denied from /user/delete. ==== Functional Permission ==== This type of permission controls if a role has access to a specific iPeer function. E.g. Admin can add instructors or instructor is not allow to add admin. Here is an example of the permission: function/user/admin/add === !Organization/Faculty === There is another level of access control in iPeer. Consider an admin at the faculty level should have access to all resources to his/her faculty, but not for other faculties. Some facts for organization/faculty: * There is a default faculty for the implementations that doesn't need this kind of level control. * A user can belongs to multiple faculties. * A course can belongs to multiple faculties. E.g., cross-listed course. * Faculty information lives in a separate table called faculty. * For the simplicity, faculty is a flat table. There is no hierarchy for faculty. {{{ #!html }}}