category		Manager	Observer	Tutor
Courses	Edit/Delete course

Instructors	Add/Edit/Delete instructors	x

Sessions	Create/edit/delete sessions	x
	View responses and comments	x	x	x
	Submit responses and comments	x		x
	Edit/delete responses/comments by others	x

Students (of a given section)	View student details	x	x	x
	Enroll/edit/delete students	x
	View others’ comments on students	x	x
	Give comments for students	x		x
	Edit/delete others’ comments	x

Policies

Access control layer is above question/comments visibility setting, meaning that questions/responses/comments will be displayed to instructors if the visibility setting is configured to be visible to instructors, but among instructors in this course, only instructor with the privilege of viewing response/comments will be able to view
Section configuration overrides course configuration. so if an instructor is set not able to view student details for the course but can view student details for students in section 1, he will be able to view students in section 1.
Sections for which configurations are not done will follow course configuration(considered as default all-sections settings)

Additional:

isDisplayedToStudents: controlling whether the students will see this instructor. right now this will be functioning in studentCourseDetailsPage--if the instructor is set to be not displayed to students, s/he will not be shown on that page; studentFeedbackSubmitPage--if the instructor is set to be not displayed to students, students cannot feedback to him/her.

For actions are not supposed to be accessed by the user based on access control settings, most of them will be disabled. Only a few links is hidden--this is mainly because IE does not recognize disabled attribute sometimes. And if the user inspect the element and remove disabled property manually and then click on the action, the action will be triggered with unauthorised exception thrown.

Some rules about privileges for instructor and instructors in the course:

1. At any point of time, there will be at least one instructor in the course who will be able to add/edit/delete instructor for the course--and this is considered as the highest privilege of an instructor.

2. If one instructor is able to edit/delete others’ comments, the privilege for viewing others’ comments will be turned on for him/her automatically. Same for feedbackResponseComment. And also because of the way commenting on student/team/section is implemented, if the give comments on student is enabled, viewing student will also be enabled.

Implementation

1. InstructorPrivileges: store the privileges of the instructor in the form of HashMaps.

*important API: isAllowedForPrivilege(String privilegeName);

isAllowedForPrivilege(String sectionName, String privilegeName);

isAllowedForPrivilege(String sectionName, String sessionName, String privilegeName); * (for eval, eval-prefix + % + evalName is used to be different from feedbackSessions)

2. InstructorPrivileges is stored in instructor in the form of Text, which is a json representation of InstructorPrivilege

3. Access control code is added to GateKeeper for necessary actions such as InstructorCourseStudentDetailsPageAction, InstructorFeedbackResponseCommentAddAction, InstructorEvalResultEditAction and so on. Besider normal checking of the privilege, the instructor’s privilege will also be checked and only if the result of isAllowedForPrivilege is true can the instructor be allowed to carry out the action. And also some buttons and links are disabled from instructors if the current instructor is not allowed for the action.

4. Actions that are not there yet: Edit Course; Edit/Delete responses by others

Note on the implementation:

The current design is stored InstructorPrivileges as json in the database and also that privilegeNames are defined in constant string in Const.java already. Adding things to instructorPrivileges may be fine in the future, removing privilegeNames may also be OK. but modifying directly will cause the problem of not being able to retrieve the right privileges for instructor. Also that this feature is scattered all over the system(especially actions and JSPs), any change may affect a lot of actions and cause the system to malfunction. Whoever wants to improve this feature must have a good understanding of the system and implementation of AccessControl mechanism.

User stories

(the user stories here are more like for future implementation or nice-to-have)

owner: can create custom roles: if default levels do not fit the need
owner: copy permissions of an existing instructor to a new instructor: avoid having to configure permissions each instructor individually
owner: bulk edit permissions: avoid having to configure permissions each instructor individually
instructor can be different access levels: co-owner, manager, observer, tutor and custom
if the instructor has custom access level, his privileges can be freely configured to have combination
instructor : see their access level--course details page : know what they can do in each course they are part of--actions that are disabled are not allowed for them
owner: see a log of actions by other instructors: to find who messed up
instructor: undo a delete action: to correct mistakes

Other similar systems

IVLE

When adding an instructor:

The role is just a label to show the status of the person. It does not have any permissions attached to it.
Access control can be set at three levels: Co-owner, Manager, Read Manager
Permissions can be given at user-object level, but not at user-object-action level

When creating a forum:

Drupal

Comprehensive description of Drupal user access control http://www.packtpub.com/article/user-access-control-drupal-6
Official user guide to access control https://drupal.org/getting-started/6/admin/user

Drupal user access control is primarily based on configurable roles.

Configuring roles:

Assigning roles:

CATME

A class is divided into sections. A section can be delegated to another faculty (can select from all faculty members in the system, including those from other universities!). Other than that, there doesn’t seem to be other access control mechanism.

PRAZE

iPeer

http://ipeer.ctlt.ubc.ca/wiki/access_control

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

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.