--- doc/gutshtml/SessionOn1.html 2002/06/28 20:30:29 1.1 +++ doc/gutshtml/SessionOn1.html 2003/07/22 14:47:00 1.2 @@ -1 +1,849 @@ - Session One: Roles, Data Storage, Parameters (Gerd)

Session One: Roles, Data Storage, Parameters (Gerd)

Domains

Every user in LON-CAPA is member of one domain. A domain can be institutional and "open", for example "msu" or "wscc" - open means that in it there can be students, authors and other users. A domain can also be functional, for example "timss_tests" or "smith_publishersÓ. Physically, every domain needs at least one dedicated library server.

Userdata

Every user in the system has one library server, which is their home server. It stores the authoritative copy of all of their records. Internally, this data is stored in a directory

 /home/httpd/lonUsers/domain/1.char/2.char/3.char/username/

for example

 /home/httpd/lonUsers/msu/s/m/i/smith/

ls -alF /home/httpd/lonUsers/msu/k/o/r/kortemey

-rw-r--r--   1 www      users       13006 May 15 12:21 activity.log

-rw-r-----   1 www      users       12413 Oct 26  2000 coursedescriptions.db

-rw-r--r--   1 www      users       11361 Oct 26  2000 coursedescriptions.hist

-rw-r-----   1 www      users       13576 Apr 19 17:45 critical.db

-rw-r--r--   1 www      users        1302 Apr 19 17:45 critical.hist

-rw-r-----   1 www      users       13512 Apr 19 17:45 email_status.db

-rw-r--r--   1 www      users        1496 Apr 19 17:45 email_status.hist

-rw-r--r--   1 www      users       12373 Apr 19 17:45 environment.db

-rw-r--r--   1 www      users         169 Apr 19 17:45 environment.hist

-rw-r-----   1 www      users       12315 Oct 25  2000 junk.db

-rw-r--r--   1 www      users        1590 Nov  4  1999 junk.hist

-rw-r-----   1 www      users       23626 Apr 19 17:45 msu_12679c3ed543a25msul1.db

-rw-r--r--   1 www      users        3363 Apr 19 17:45 msu_12679c3ed543a25msul1.hist

-rw-r-----   1 www      users       17242 Nov 13  2000 msu_1827338c7d339a3msul1.db

-rw-r--r--   1 www      users        1986 Nov 13  2000 msu_1827338c7d339a3msul1.hist

-rw-r-----   1 www      users       18497 Dec 21 11:25 msu_1827338c7d339b4msul1.db

-rw-r--r--   1 www      users        3801 Dec 21 11:25 msu_1827338c7d339b4msul1.hist

-rw-r-----   1 www      users       12470 Apr 19 17:45 nohist_annotations.db

-rw-r-----   1 www      users       13395 Nov 15  2000 nohist_bookmarks.db

-rw-r-----   1 www      users      104264 Apr 19 17:45

                             nohist_calculatedsheets_msu_12679c3ed543a25msul1.db

-rw-r-----   1 www      users       13248 Apr  5 17:18

                             nohist_calculatedsheets_msu_1827338c7d339b4msul1.db

-rw-r-----   1 www      users       12568 Oct 28  2000 nohist_coursedescriptions.db

-rw-r-----   1 www      users      765954 Apr 19 17:45 nohist_email.db

-rw-r--r--   1 www      users      710631 Apr 19 17:45 nohist_email.hist

-rw-r--r--   1 www      users          13 Apr 19 17:45 passwd

-rw-r--r--   1 www      users       12802 May  3 13:08 roles.db

-rw-r--r--   1 www      users        1316 Apr 12 16:05 roles.hist

Fig.2.1.1 Ð Directory listing of userÕs home directory

Files ending on .db are GDBM files, files ending on .hist are logs of entries to these files. Filenames starting with ÒnohistÓ do not keep history files. passwd stores the login mechanism and password (if applicable).

environment stores name-value pairs that are automatically added to the session environment at login time, for example the full name, etc.

roles stores the userroles.

critical, nohist_email, and email_status are used by the messaging mechanisms

Files with a course-ID as name, for example msu_12679c3ed543a25msul1.db, store performance data for that student in the course, as stored by store and restore in lonnet.

Other files are caches, for example for previously calculated spreadsheets, etc.

Courses

Courses are assigned to users, not vice versa. Internally, courses are handled like users without login privileges. The username is a unique ID, for example msu_12679c3ed543a25msul1 Ð every course in every semester has a unique ID, there is no semester transition. The userdata of the course includes the full name of the course, a pointer to its top-level resource map (Òcourse mapÓ), and any associated deadlines, spreadsheets, etc., as well as a course enrollment list. The latter is somewhat redundant, since in principle, this list could be produced by going through the roles of all users, and looking for the valid role of being student in that course.

ls -alF /home/httpd/lonUsers/msu/1/2/6/12679c3ed543a25msul1/

-rw-r-----   1 www      users       17155 Apr 25 16:20 classlist.db

-rw-r--r--   1 www      users       60912 Apr 25 16:20 classlist.hist

-rw-r-----   1 www      users       12354 Jan  4 16:40 environment.db

-rw-r--r--   1 www      users          82 Jan  4 16:40 environment.hist

-rw-r-----   1 www      users      103030 May 15 14:47 nohist_calculatedsheets.db

-rw-r-----   1 www      users       13050 May  9 21:04 nohist_expirationdates.db

-rw-r--r--   1 www      users           6 Jan  4 16:40 passwd

-rw-r-----   1 www      users       17457 May  9 21:04 resourcedata.db

-rw-r--r--   1 www      users        8888 May  9 21:04 resourcedata.hist

Fig.2.1.2 Ð Directory listing of courseÕs home directory

classlist is this list of students in the course, environment includes the courseÕs full name, etc, and resourcedata are deadlines, etc (parameters for homework).

Roles

Users keep their login, data, preferences, etc, over their complete tenure. Every user can have several roles, and the roles can change over the lifetime of a username. For example, over the course of studies, a student username assumes the role of "student" in different courses. Roles can have start and expiration dates.

Example: User smith at msu

Instructor

msu_12679c3ed543a25msul1

  

Course Coordinator

msu_12679c3ed543a25msul1

From July 1st, 2001 to December 30th, 2001

Instructor

msu_18879c3ed543a25msul2

From Jan 1st, 2001 to June 30th, 2001

Resource Author

msu

From Aug 15th, 2000

Student

msu_82679c3gd543a35msul1

From July 1st, 2001 to December 30th, 2001 

Fig.2.1.3 Ð Sample Instructor Roles


Example: User jones at msu

Custom Role "Helproom TA (smith at msu)"

msu_82679c3gd543a35msul1

From July 1st, 2001 to December 30th, 2001

Student

msu_02679c3gq543a35msul1

From Jan 1st, 2001 to June 30th, 2001

Student

umn_82679c3gd543a35umnl2

From July 1st, 2001 to December 30th, 2001

Exam Proctor

msu_82679c3gd543a35msul1

Feb 21st, 2001, 1pm to 3pm

Fig.2.1.4 Ð Sample Student Roles

Custom Roles

Course Coordinators are able to define named "Custom Roles" for their courses within a pre-defined set of capabilities. In addition to these custom roles, there are three standard course faculty/staff roles defined, Instructor, Exam Proctor and TA. The instructor of record in a small class is likely to be "Course Coordinator" and "Instructor" during the term when the course is running, and might remain course coordinator afterwards. Course coordinator can assign themselves new roles for their course anytime.

 

Custom role definitions are stored in the roles.db file of the role author.

Choose a Role, Role Privileges

lonroles is a handler that allows a user to switch roles in mid-session. LON-CAPA attempts to work with ÒNo Role SpecifiedÓ as widely as possible, but certain handlers for example need specification which course they should act on, etc. Both in this scenario, and when the handler determines via lonnetÕs &allowed function that a certain action is not allowed, lonroles is used as errorhandler. lonroles can also be accessed via the CRS button in the Remote Control. Fig. 2.1.5 shows a sample output of lonroles.

Fig. 2.1.5 Ð Sample Roles Choice in lonroles.pm

System: /

á       Browse resources

á       Generate anonymous statistics

á       Create a Course Custom Role

Domain: msu

á       Assemble resources

á       Browse resources

á       Grant/revoke role of Administrator (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Author (UNIX authenticated)

á       Grant/revoke role of Co-Author (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Course Coordinator (UNIX authenticated)

á       Grant/revoke Course Custom Role (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Domain Guest (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Exam Proctor (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Instructor (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Librarian (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Copy resources

á       Grant/revoke role of Student (UNIX authenticated, Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Teaching Assistant (UNIX authenticated, Internally authenticated, Kerberos authenticated)

Course: lbs267L Lab SS01

á       Assemble resources

á       Grant/revoke Course Custom Role (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Exam Proctor (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Instructor (Internally authenticated, Kerberos authenticated)

á       Copy resources

á       Grant/revoke role of Student (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Teaching Assistant (Internally authenticated, Kerberos authenticated)

á       Create, edit, modify and publish resources

á       Generate anonymous statistics

á       Set assessment parameters

á       Send broadcast and receipt-required email

á       View grades

Course: lbs267 Lecture SS01

á       Assemble resources

á       Grant/revoke Course Custom Role (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Exam Proctor (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Instructor (Internally authenticated, Kerberos authenticated)

á       Copy resources

á       Grant/revoke role of Student (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Teaching Assistant (Internally authenticated, Kerberos authenticated)

á       Create, edit, modify and publish resources

á       Generate anonymous statistics

á       Set assessment parameters

á       Send broadcast and receipt-required email

á       View grades

Course: Demo Course

á       Assemble resources

á       Grant/revoke Course Custom Role (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Exam Proctor (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Instructor (Internally authenticated, Kerberos authenticated)

á       Copy resources

á       Grant/revoke role of Student (Internally authenticated, Kerberos authenticated)

á       Grant/revoke role of Teaching Assistant (Internally authenticated, Kerberos authenticated)

á       Create, edit, modify and publish resources

á       Generate anonymous statistics

á       Set assessment parameters

á       Send broadcast and receipt-required email

á       View grades

Construction Space: User: korte, Domain: msu

Fig. 2.1.6 Ð Sample Set of Privileges

Fig. 2.1.6 shows a common set of privileges for the user roles in Fig. 2.1.5. The plain text explanations of the various roles and the extent of them is drawn from /home/httpd/rolesplain.tab, see Fig. 2.1.7.

[www@zaphod www]$ more /home/httpd/lonTabs/rolesplain.tab

s:system wide

d:domain wide

c:course wide

U:UNIX authenticated

I:Internally authenticated

K:Kerberos authenticated

C:according to course preferences

S:according to custom role settings

R:according to resource settings

L:unless locked

X:according to user session state

F:no restrictions

cm:No Role, Cumulative Privileges

su:Superuser

dc:Domain Coordinator

cc:Course Coordinator

in:Instructor

ta:Teaching Assistant

ep:Exam Proctor

cr:Course Custom Role

st:Student

ad:Administrator

li:Librarian

au:Author

dg:Domain Guest

ca:Co-Author

csu:Grant/revoke role of Superuser

cdc:Grant/revoke role of Domain Coordinator

ccc:Grant/revoke role of Course Coordinator

cin:Grant/revoke role of Instructor

cta:Grant/revoke role of Teaching Assistant

cep:Grant/revoke role of Exam Proctor

ccr:Grant/revoke Course Custom Role

cst:Grant/revoke role of Student

cad:Grant/revoke role of Administrator

cli:Grant/revoke role of Librarian

cau:Grant/revoke role of Author

cdg:Grant/revoke role of Domain Guest

cca:Grant/revoke role of Co-Author

mcr:Create a Course Custom Role

mau:Modify authentication mechanism and data for a user

bre:Browse resources

are:Assemble resources

cre:Copy resources

ere:Create, edit, modify and publish resources

mme:Modify metadata for a resource

vgr:View grades

mgr:Modify grades

gan:Generate anonymous statistics

dcm:Disable all communication among students

sma:Send internal email

srm:Send broadcast and receipt-required email

pch:Post to chatrooms and bulletin boards

dch:Delete messages from bulletin boards

pac:Post anonymously

rin:Get identity behind anonymous postings

las:Lock and unlock assessments

opa:Set assessment parameters

ain:Assume a student's identity

Fig. 2.1.7 Ð Explanation of Privilege Shorthands

Role Initialization

The privileges for a user are established at login time and stored in the session environment. A consequence is that a new role does not become active till the next login. Handlers are able to query for privileges using lonnetÕs &allowed function. When a user first logs in, their role is the ÒcommonÓ role, which means that they have the sum of all of their privileges. During a session it might become necessary to choose a particular role, which as a consequence also limits the user to only the privileges in that particular role.

[www@zaphod www]$ more /home/httpd/lonTabs/roles.tab

su:s csu&U:sma:mau:cdc&U

dc:s sma

dc:d cli&UIK:cau&U:cdg&UIK:mau:ccc&U:cin&UIK:cta&UIK:cep&UIK:ccr&UIK:cst&UIK:cad&UIK

cc:s bre:sma:mcr

cc:c cin&IK:cta&IK:cep&IK:ccr&IK:cst&IK:are:cre:ere:vgr:gan:srm:opa

in:s sma

in:d bre

in:c vgr:mgr:gan:dcm:srm:pch:dch:pac:rin:las:opa

ta:d sma

ta:c bre&RL:vgr&CR:mgr&CR:srm:pch:dch:pac

ep:d sma

ep:c bre&R:mgr&R:dcm:las

cr:d sma

cr:c bre&R:vgr&SCR:mgr&SCR:gan&SCR:dcm&SC:srm&SC:pch:dch&S:pac:rin&S:las&SR:opa&SR

st:d sma&L

st:c bre&RXL:pch&L:pac&CL

ad:d sma

ad:c bre:gan:vgr:srm

li:s gan:sma

li:d mme

au:s gan:sma

au:d bre:are:cre:ere:cca&IK

ca:s gan:sma

ca:d bre:are:cre:ere

dg:d bre&R

Fig. 2.1.8 Ð Privileges by roles and extent

Role Assignment

Fig. 2.1.9 Ð Assigning privileges to a user

 


\ No newline at end of file + + + + +Session One: Roles, Data Storage, Parameters (Gerd) + + + +
+

Session One: Roles, Data Storage, Parameters (Gerd)

+

Domains

+

Every user in LON-CAPA is member of one domain. + A domain can be institutional and "open", for example "msu" + or "wscc" - open means that in it there can be students, authors + and other users. A domain can also be functional, for example "timss_tests" + or "smith_publishersÓ. Physically, every domain needs at least one dedicated + library server.

+

Userdata

+

Every user in the system has one library server, which is their home server. + It stores the authoritative copy of all of their records. Internally, this + data is stored in a directory

+

 /home/httpd/lonUsers/domain/1.char/2.char/3.char/username/

+

for example

+

 /home/httpd/lonUsers/msu/s/m/i/smith/

+
+

ls -alF /home/httpd/lonUsers/msu/k/o/r/kortemey

+

-rw-r--r--   1 www      users       + 13006 May 15 12:21 activity.log

+

-rw-r-----   1 www      users       + 12413 Oct 26  2000 coursedescriptions.db

+

-rw-r--r--   1 www      users       + 11361 Oct 26  2000 coursedescriptions.hist

+

-rw-r-----   1 www      users       + 13576 Apr 19 17:45 critical.db

+

-rw-r--r--   1 www      users        + 1302 Apr 19 17:45 critical.hist

+

-rw-r-----   1 www      users       + 13512 Apr 19 17:45 email_status.db

+

-rw-r--r--   1 www      users        + 1496 Apr 19 17:45 email_status.hist

+

-rw-r--r--   1 www      users       + 12373 Apr 19 17:45 environment.db

+

-rw-r--r--   1 www      users         + 169 Apr 19 17:45 environment.hist

+

-rw-r-----   1 www      users       + 12315 Oct 25  2000 junk.db

+

-rw-r--r--   1 www      users        + 1590 Nov  4  1999 junk.hist

+

-rw-r-----   1 www      users       + 23626 Apr 19 17:45 msu_12679c3ed543a25msul1.db

+

-rw-r--r--   1 www      users        + 3363 Apr 19 17:45 msu_12679c3ed543a25msul1.hist

+

-rw-r-----   1 www      users       + 17242 Nov 13  2000 msu_1827338c7d339a3msul1.db

+

-rw-r--r--   1 www      users        + 1986 Nov 13  2000 msu_1827338c7d339a3msul1.hist

+

-rw-r-----   1 www      users       + 18497 Dec 21 11:25 msu_1827338c7d339b4msul1.db

+

-rw-r--r--   1 www      users        + 3801 Dec 21 11:25 msu_1827338c7d339b4msul1.hist

+

-rw-r-----   1 www      users       + 12470 Apr 19 17:45 nohist_annotations.db

+

-rw-r-----   1 www      users       + 13395 Nov 15  2000 nohist_bookmarks.db

+

-rw-r-----   1 www      users      + 104264 Apr 19 17:45

+

                             + nohist_calculatedsheets_msu_12679c3ed543a25msul1.db

+

-rw-r-----   1 www      users       + 13248 Apr  5 17:18

+

                             + nohist_calculatedsheets_msu_1827338c7d339b4msul1.db

+

-rw-r-----   1 www      users       + 12568 Oct 28  2000 nohist_coursedescriptions.db

+

-rw-r-----   1 www      users      + 765954 Apr 19 17:45 nohist_email.db

+

-rw-r--r--   1 www      users      + 710631 Apr 19 17:45 nohist_email.hist

+

-rw-r--r--   1 www      users          + 13 Apr 19 17:45 passwd

+

-rw-r--r--   1 www      users       + 12802 May  3 13:08 roles.db

+

-rw-r--r--   1 www      users        + 1316 Apr 12 16:05 roles.hist

+
+

Fig.2.1.1 Ð Directory listing of userÕs home directory

+

Files ending on .db are GDBM + files, files ending on .hist + are logs of entries to these files. Filenames starting with ÒnohistÓ do not + keep history files. passwd + stores the login mechanism and password (if applicable).

+

environment stores name-value + pairs that are automatically added to the session environment at login time, + for example the full name, etc.

+

roles stores the userroles.

+

critical, nohist_email, and email_status are used by the messaging + mechanisms

+

Files with a course-ID as name, for example msu_12679c3ed543a25msul1.db, + store performance data for that student in the course, as stored by store and restore in lonnet.

+

Other files are caches, for example for previously calculated spreadsheets, + etc.

+

Courses

+

Courses are assigned to users, not vice versa. + Internally, courses are handled like users without login privileges. The username + is a unique ID, for example msu_12679c3ed543a25msul1 Ð every course in every semester has a unique ID, there + is no semester transition. The userdata of the course includes the full name + of the course, a pointer to its top-level resource map (Òcourse mapÓ), and + any associated deadlines, spreadsheets, etc., as well as a course enrollment + list. The latter is somewhat redundant, since in principle, this list could + be produced by going through the roles of all users, and looking for the valid + role of being student in that course.

+
+

ls -alF /home/httpd/lonUsers/msu/1/2/6/12679c3ed543a25msul1/

+

-rw-r-----   1 www      users       + 17155 Apr 25 16:20 classlist.db

+

-rw-r--r--   1 www      users       + 60912 Apr 25 16:20 classlist.hist

+

-rw-r-----   1 www      users       + 12354 Jan  4 16:40 environment.db

+

-rw-r--r--   1 www      users          + 82 Jan  4 16:40 environment.hist

+

-rw-r-----   1 www      users      + 103030 May 15 14:47 nohist_calculatedsheets.db

+

-rw-r-----   1 www      users       + 13050 May  9 21:04 nohist_expirationdates.db

+

-rw-r--r--   1 www      users           + 6 Jan  4 16:40 passwd

+

-rw-r-----   1 www      users       + 17457 May  9 21:04 resourcedata.db

+

-rw-r--r--   1 www      users        + 8888 May  9 21:04 resourcedata.hist

+
+

Fig.2.1.2 Ð Directory listing of courseÕs home directory

+

classlist + is this list of students in the course, environment includes the courseÕs full name, + etc, and resourcedata + are deadlines, etc (parameters for homework).

+

Roles

+

Users keep their login, data, preferences, + etc, over their complete tenure. Every user can have several roles, and the + roles can change over the lifetime of a username. For example, over the course + of studies, a student username assumes the role of "student" in + different courses. Roles can have start and expiration dates.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Example: User smith at msu

Instructor

msu_12679c3ed543a25msul1

 

Course Coordinator

msu_12679c3ed543a25msul1

From July + 1st, 2001 to December 30th, 2001

Instructor

msu_18879c3ed543a25msul2

From Jan + 1st, 2001 to June 30th, 2001

Resource Author

msu

From Aug + 15th, 2000

Student

msu_82679c3gd543a35msul1

From July + 1st, 2001 to December 30th, 2001 

+

Fig.2.1.3 Ð Sample Instructor Roles

+
+ + + + + + + + + + + + + + + + + + + + + + + + +

Example: User jones at msu

Custom Role + "Helproom TA (smith at msu)"

msu_82679c3gd543a35msul1

From July + 1st, 2001 to December 30th, 2001

Student

msu_02679c3gq543a35msul1

From Jan + 1st, 2001 to June 30th, 2001

Student

umn_82679c3gd543a35umnl2

From July + 1st, 2001 to December 30th, 2001

Exam Proctor

msu_82679c3gd543a35msul1

Feb 21st, + 2001, 1pm to 3pm

+

Fig.2.1.4 Ð Sample Student Roles

+

Custom Roles

+

Course Coordinators are able to define named "Custom Roles" for + their courses within a pre-defined set of capabilities. In addition to these + custom roles, there are three standard course faculty/staff roles defined, + Instructor, Exam Proctor and TA. The instructor of record in a small class + is likely to be "Course Coordinator" and "Instructor" + during the term when the course is running, and might remain course coordinator + afterwards. Course coordinator can assign themselves new roles for their course + anytime.

+
+
+

 

+

Custom role definitions are stored in the roles.db file of the + role author.

+

Choose a Role, Role Privileges

+

lonroles is a handler that + allows a user to switch roles in mid-session. LON-CAPA attempts to work with ÒNo Role + SpecifiedÓ as widely as possible, but certain handlers for example need specification + which course they should act on, etc. Both in this scenario, and when the + handler determines via lonnetÕs + &allowed function that + a certain action is not allowed, lonroles + is used as errorhandler. lonroles + can also be accessed via the CRS button in the Remote Control. Fig. 2.1.5 shows a sample output of lonroles.

+

+

Fig. 2.1.5 Ð Sample Roles Choice + in lonroles.pm

+
+

System: /

+
+
+

á       Browse resources

+

á       Generate anonymous statistics

+

á       Create a Course Custom Role

+ +
+
+

Domain: msu

+
+
+

á       + Assemble resources

+

á       + Browse resources

+

á       + Grant/revoke role of Administrator + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Author + (UNIX authenticated)

+

á       + Grant/revoke role of Co-Author + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Course + Coordinator (UNIX authenticated)

+

á       + Grant/revoke Course Custom Role + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Domain + Guest (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Exam Proctor + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Instructor + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Librarian + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Copy resources

+

á       + Grant/revoke role of Student + (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Teaching + Assistant (UNIX authenticated, Internally authenticated, Kerberos authenticated)

+ +
+
+

Course: lbs267L + Lab SS01

+
+
+

á       + Assemble resources

+

á       + Grant/revoke Course Custom Role + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Exam Proctor + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Instructor + (Internally authenticated, Kerberos authenticated)

+

á       + Copy resources

+

á       + Grant/revoke role of Student + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Teaching + Assistant (Internally authenticated, Kerberos authenticated)

+

á       + Create, edit, modify and publish + resources

+

á       + Generate anonymous statistics

+

á       + Set assessment parameters

+

á       + Send broadcast and receipt-required + email

+

á       + View grades

+
+
+

Course: lbs267 + Lecture SS01

+
+
+

á       + Assemble resources

+

á       + Grant/revoke Course Custom Role + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Exam Proctor + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Instructor + (Internally authenticated, Kerberos authenticated)

+

á       + Copy resources

+

á       + Grant/revoke role of Student + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Teaching + Assistant (Internally authenticated, Kerberos authenticated)

+

á       + Create, edit, modify and publish + resources

+

á       + Generate anonymous statistics

+

á       + Set assessment parameters

+

á       + Send broadcast and receipt-required + email

+

á       + View grades

+
+
+

Course: Demo + Course

+
+
+

á       + Assemble resources

+

á       + Grant/revoke Course Custom Role + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Exam Proctor + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Instructor + (Internally authenticated, Kerberos authenticated)

+

á       + Copy resources

+

á       + Grant/revoke role of Student + (Internally authenticated, Kerberos authenticated)

+

á       + Grant/revoke role of Teaching + Assistant (Internally authenticated, Kerberos authenticated)

+

á       + Create, edit, modify and publish + resources

+

á       + Generate anonymous statistics

+

á       + Set assessment parameters

+

á       + Send broadcast and receipt-required + email

+

á       + View grades

+
+
+

Construction + Space: User: korte, Domain: msu

+
+

Fig. 2.1.6 Ð Sample Set of Privileges

+

Fig. 2.1.6 shows a common set of + privileges for the user roles in Fig. 2.1.5. The plain text explanations of the various roles + and the extent of them is drawn from /home/httpd/rolesplain.tab, + see Fig. 2.1.7.

+
+

[www@zaphod www]$ more /home/httpd/lonTabs/rolesplain.tab

+

s:system wide

+

d:domain wide

+

c:course wide

+

U:UNIX authenticated

+

I:Internally authenticated

+

K:Kerberos authenticated

+

C:according to course preferences

+

S:according to custom role settings

+

R:according to resource settings

+

L:unless locked

+

X:according to user session + state

+

F:no restrictions

+

cm:No Role, Cumulative Privileges

+

su:Superuser

+

dc:Domain Coordinator

+

cc:Course Coordinator

+

in:Instructor

+

ta:Teaching Assistant

+

ep:Exam Proctor

+

cr:Course Custom Role

+

st:Student

+

ad:Administrator

+

li:Librarian

+

au:Author

+

dg:Domain Guest

+

ca:Co-Author

+

csu:Grant/revoke role of Superuser

+

cdc:Grant/revoke role of Domain + Coordinator

+

ccc:Grant/revoke role of Course + Coordinator

+

cin:Grant/revoke role of Instructor

+

cta:Grant/revoke role of Teaching + Assistant

+

cep:Grant/revoke role of Exam + Proctor

+

ccr:Grant/revoke Course Custom + Role

+

cst:Grant/revoke role of Student

+

cad:Grant/revoke role of Administrator

+

cli:Grant/revoke role of Librarian

+

cau:Grant/revoke role of Author

+

cdg:Grant/revoke role of Domain + Guest

+

cca:Grant/revoke role of Co-Author

+

mcr:Create a Course Custom Role

+

mau:Modify authentication mechanism + and data for a user

+

bre:Browse resources

+

are:Assemble resources

+

cre:Copy resources

+

ere:Create, edit, modify and + publish resources

+

mme:Modify metadata for a resource +

+

vgr:View grades

+

mgr:Modify grades

+

gan:Generate anonymous statistics

+

dcm:Disable all communication + among students

+

sma:Send internal email

+

srm:Send broadcast and receipt-required + email

+

pch:Post to chatrooms and bulletin + boards

+

dch:Delete messages from bulletin + boards

+

pac:Post anonymously

+

rin:Get identity behind anonymous + postings

+

las:Lock and unlock assessments

+

opa:Set assessment parameters

+

ain:Assume a student's identity +

+
+

Fig. 2.1.7 Ð Explanation of Privilege Shorthands

+

Role Initialization

+

The privileges for a user are established at login time and stored in the + session environment. A consequence is that a new role does not become active + till the next login. Handlers are able to query for privileges using + lonnetÕs &allowed function. When a user first logs in, their role is the + ÒcommonÓ role, which means that they have the sum of all of their privileges. + During a session it might become necessary to choose a particular role, which + as a consequence also limits the user to only the privileges in that particular + role.

+
+

[www@zaphod www]$ more /home/httpd/lonTabs/roles.tab

+

su:s csu&U:sma:mau:cdc&U

+

dc:s sma

+

dc:d cli&UIK:cau&U:cdg&UIK:mau:ccc&U:cin&UIK:cta&UIK:cep&UIK:ccr&UIK:cst&UIK:cad&UIK

+

cc:s bre:sma:mcr

+

cc:c cin&IK:cta&IK:cep&IK:ccr&IK:cst&IK:are:cre:ere:vgr:gan:srm:opa

+

in:s sma

+

in:d bre

+

in:c vgr:mgr:gan:dcm:srm:pch:dch:pac:rin:las:opa

+

ta:d sma

+

ta:c bre&RL:vgr&CR:mgr&CR:srm:pch:dch:pac

+

ep:d sma

+

ep:c bre&R:mgr&R:dcm:las

+

cr:d sma

+

cr:c bre&R:vgr&SCR:mgr&SCR:gan&SCR:dcm&SC:srm&SC:pch:dch&S:pac:rin&S:las&SR:opa&SR

+

st:d sma&L

+

st:c bre&RXL:pch&L:pac&CL

+

ad:d sma

+

ad:c bre:gan:vgr:srm

+

li:s gan:sma

+

li:d mme

+

au:s gan:sma

+

au:d bre:are:cre:ere:cca&IK

+

ca:s gan:sma

+

ca:d bre:are:cre:ere

+

dg:d bre&R

+
+

Fig. 2.1.8 Ð Privileges by roles and extent

+

Role Assignment

+

+

Fig. 2.1.9 Ð Assigning privileges to a user

+ +
+ +

 

+
+
+
+ +