Changes between Version 3 and Version 4 of access_control

Timestamp:

2012-02-18T00:20:20Z (13 years ago)

Author:

Pan Luo

Comment:

--

access_control

@@ -7 +7 @@
 === User ===
 
-* A user have different role(s) in the system.
+* 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 ===
@@ -37 +36 @@
 
 ==== !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 /usr/delete.
+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.
+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 don't need this kind of level control.
+* A user can belongs to multiple faculties.
+* Faculty information lives in a separate table called faculty.
+* For the simplicity, faculty is a flat table. There is no hierarchy for faculty.