Return to Domain_Configuration_Auto_Enrollment.tex CVS log

Up to [LON-CAPA] / loncom / html / adm / help / tex

Annotation of loncom/html/adm/help/tex/Domain_Configuration_Auto_Enrollment.tex, revision 1.8

1.1       raeburn     1: \label{Domain_Configuration_Auto_Enrollment}
                      2: If your institution can provide access to roster information for courses
                      3: using LON-CAPA then your domain can offer automated enrollment once
                      4: localenroll.pm has been customized on each of the library servers
                      5: in your domain which serves as a home server for one or more courses.
                      6: The required customization is the creation of connections to rosters
                      7: for institutional course sections providing enrollment to each LON-CAPA
                      8: course. These connections can involve queries of database tables,
                      9: in real time, or can involve retrieval from a data source which is
                     10: only updated periodically.
                     11: 
1.7       raeburn    12: There are four configuration options: 
1.1       raeburn    13: 
                     14: \begin{itemize}
1.7       raeburn    15: \item \textbf{Set auto-enrollment as active or inactive in the domain} 
                     16: \item \textbf{Set the username:domain used in the notification messages sent when
                     17: changes in enrollment occur as a result of auto-enrollment updates.}
1.1       raeburn    18: By setting these to a specific user (you might create one for this
                     19: purpose), you can view all auto-enrollment change messages for the
                     20: entire domain by viewing the contents of the sent messages folder for that user.
1.7       raeburn    21: \item \textbf{Automatically assign co-ownership.}
1.4       raeburn    22: If this is set to yes, then whenever a Course Coordinator role is assigned 
                     23: in a course with an institutional code, a check is made to see if the user 
                     24: to whom the role is being assigned is officially listed as instructional
                     25: personnel. If so, and the user is not the course owner, then the user will
1.6       bisitz     26: be identified as a co-owner. Co-owners are listed in the course/community catalog, and
1.7       raeburn    27: also in the pop-up window displayed when picking a course (e.g., for cloning).  
                     28: For the validation to work the validate\_instcode() routine in localenroll.pm
1.4       raeburn    29: must have been customized to include the username supplied as the third argument
                     30: in the query made to the institutional data source which ties instructors to
                     31: institutional codes.
1.7       raeburn    32: \item \textbf{Failsafe for no drops when institutional data missing.}
                     33: In a course for which enrollment comes from more than one institutional
                     34: course section (including cross-listing), there is a possibility that 
                     35: institutional data retrieval might succeed for some, but not all sections.
                     36: In order to avoid expiring student roles in sections for which institutional
                     37: enrollment data could not be retrieved, a failsafe value can be set.  When the
                     38: existing enrollment in a LON-CAPA course section exceeds that failsafe value (an integer),
                     39: dropping of existing students (identified as belonging to the affected section(s)) 
                     40: by the automated enrollment process is disabled. The domain default for the failsafe  
                     41: set by a Domain Coordinator can be overridden in a specific course by a Course Coordinator. 
1.1       raeburn    42: \end{itemize}
1.4       raeburn    43: 
1.1       raeburn    44: Auto-enrollment settings for each course consist of items set by a
1.8     ! raeburn    45: Domain Coordinator within the {}``Modify Course'' area,
1.2       raeburn    46: and those items set in a course context from the 
1.8     ! raeburn    47: {}``\underbar{Automated Enrollment Manager}''
        !            48: link in the ``Manage Users'' 
1.1       raeburn    49: menu. This link is only displayed if auto-enrollment has been set
                     50: to be active in the domain.
                     51: 
                     52: The items which must be set by a Domain Coordinator include: 
                     53: 
                     54: \begin{itemize}
                     55: \item institutional code (used in mapping institutional rosters to LON-CAPA
                     56: courses)
                     57: \item default authentication
                     58: \item course owner
                     59: \end{itemize}
                     60: Your institution may have policies in place to control who may have
                     61: access to student information contained within course rosters. In
                     62: such cases, assignment of an appropriate course owner in LON-CAPA
                     63: may facilitate access to institutional rosters. When a course is first
                     64: created the initial Course Coordinator chosen will be identified as
                     65: the course owner. If, instead a course is created using an uploaded
                     66: XML course description file, the XML file will include tags to define
                     67: the username and domain of the course owner.
                     68: 
                     69: Settings which control auto-enrollment which are modifiable by a Course
1.2       raeburn    70: Coordinator are described in the \ref{Course_Automated_Enrollment} help page.
1.1       raeburn    71: 
                     72: The auto-enrollment process will update user information (name, e-mail
                     73: address, studentID etc.) for any student who is being added to the
                     74: course, but will not change it in other case (i.e., drops, section
                     75: switches) should there be a difference between the values in the institutional
                     76: roster and the values in the LON-CAPA classlist. To change user information
                     77: for students already in the course, the Auto-update process must be run
                     78: (see below).
                     79: 
                     80: Warnings will be written to the Auto-enrollment log file found in
                     81: /home/httpd/perl/logs if a possible username change is detected. Although
                     82: the username is the unique identifier in LON-CAPA, the studentID operates
                     83: as an additional, mostly unique identifier. The same studentID may
                     84: not be assigned to more than one user - if an existing studentID is
                     85: assigned to adifferent user, the change will not occur, unless forced
                     86: (there's a checkbox for that). A blank studentID can be assigned,
                     87: and in this case multiple users can share the same studentID. StudentIDs
1.3       raeburn    88: are used for LON-CAPA grading of bubblesheets, and are also used
1.1       raeburn    89: to detect changes in username by the auto-enrollment and auto-update
                     90: processes.
                     91: 
                     92: At present LON-CAPA does not support username changes, although this
                     93: functionality will be supported in the future. In the meantime, what
                     94: you must do for users who switch username mid-semester (assuming institutional
                     95: authentication will no longer authenticate the user's old username)
                     96: is to convert the authentication type in LON-CAPA for the user to
1.8     ! raeburn    97: {}``internal'', set an initial password, make sure that
1.1       raeburn    98: permanent e-mail is set for the user, then e-mail the user the initial
1.8     ! raeburn    99: password, and ask them to use the {}``\underbar{Forgot password?}''
1.1       raeburn   100: link on the log-in page to change the password to something secure.