[LON-CAPA-admin] Course Catalog, Auto-Enrollment

[Stuart Peter Raeburn]

Stefan,

> As we understand how auto enrollment works, we think that we can build 
> a scenario like this: 
> a) Students register for LON-CAPA courses using a HTML form 
> b) The form creates XML files in /home/http/perl/tmp/ and stores 
>  the enrollment data from the form 
> c) The nightly auto enrollment job (Autoenroll.pl and localenroll.pm) adds 
> the new students to the courses 
>  
> Consider, that we have NO university server which provides student´s 
> course data.  
>

Autoenroll.pl and localenroll.pm were designed for the situation where you 
do have access to an institutional source of official course rosters.  
However, it would be possible to work around this requirement in the general 
way you describe. 

> Form for self enrollment 
> Is it right, that a) and b) form our scenario are not implemented in 
> LON-CAPA and have to be programmed by our own? 
>

LON-CAPA does not currently provide a method for users to self-enroll, 
although it is something that has been discussed in the past.  The key 
question is the way the username will be determined for the self-enrolling 
user.
(1) You probably want to prevent users enrolling in the same course multiple 
times with different usernames.
(2) You will want to prevent users adopting usernames which will conflict 
with current or future official usernames at your institution, unless they 
are actually that user.
(3) You probably want to prevent users "self-enrolling" other people, 
without their consent. 

It seems to me that if an HTML form was used to allow self-enrollment it 
should do the following:
(a) For institutional users: use authenticated access to the form, which 
most likely means that a domain would reuse its existing localauth.pm 
mechanism, or alternatively SSO-style authentication
(b) For other, non-institutional usernames, a modified e-mail address would 
be used as the username (e.g., replacing the @ with -, since I don't believe 
@ is allowed in LON-CAPA usernames currently), and employ a two-step process 
to actually complete enrollment (similar to the way an internally 
authenticated user can currently reset a forgotten password). 

Even with these approaches, if you allow users to self-enroll and create 
their own usernames which employ internal authentication, it would not be 
possible to prevent scenario (1).  By default each user will get a 20Mb 
portfolio to store their own files (although a Domain Coordinator can change 
the quota for each user). 

I would not write information for self-enrolling users directly to 
/home/httpd/perl/tmp, as the classlist.xml files placed there are removed 
automatically after Autoenroll.pl runs.  It is also possible for a Course 
Coordinator to use ENRL -> Automated Enrollment Manager -> "Update Roster 
Now" to add/drop students based on the contents of the current classlist.  
The issue here is that if auto-drops are enabled, you will drop any 
previously enrolled users.  You will need to maintain "permanent" 
classlist(s) somewhere other than /home/httpd/perl/tmp. As users complete 
the self-enrollment form, you would "append" them to the permanent 
classlists.  Your fetch-enrollment() subroutine would then copy the contents 
of your "permanent" classlist data source to the temporary XML file in 
/home/httpd/perl/tmp each time it ran. 

>  
>  
> localenroll.pm from msu 
> CVS: /modules/mus/localenroll.pm 
> Is this the current version which you use at MSU?  
>
The MSU version in use on our production library server here is one or two 
versions back from the latest one I committed to 
/modules/msu/localenroll.pm.  However, it does have all the subroutines 
defined in /loncom/enrollment/localenroll.pm rev 1.17 which shipped with 
LON-CAPA 2.3.2
(see next comment). 

>  
> localenroll.pm version 
> Why do I find localenroll.pm v1.10 in /home/http/lib/perl/, but v1.17 seems to be the current one?

When you run ./UPDATE to update your LON-CAPA distribution there are a 
number of files in /home/httpd/lib/perl which the install process will not 
overwrite.  These files are the locally customized versions of 
localenroll.pm, localauth.pm, and localstudentphoto.pm.  The corresponding 
standard versions (which will be updated if the LON-CAPA release you are 
updating to contains newer files) are: localenroll-std.pm, localauth-std.pm, 
and localstudentphoto-std.pm.  The version number for localenroll-std.pm 
should be 1.17.  If you do customize localenroll.pm, you will probably want 
to maintain your own versioning. I expect that 1.10 is the version number 
you see included because that was the current version number for the 
standard (uncustomized file) when you first installed LON-CAPA. 

Changes to localenroll-std.pm occur when an UPDATE is run if wording of 
documentation has changed or new subroutines have been added.  The intent is 
that you should copy any new subroutine stubs which are present in 
localenroll-std.pm but missing from your custom localenroll.pm. 

>  
>  
> Aim of course catalog 
> Am I right, that the course catalog can be only used to display existing courses, but not for enrollment?  
>

As it exists today, the course catalog is used to display information about 
existing courses (with institutional codes).  Logged-in users can display 
more information (including access dates and auto-enrollment settings) than 
unauthenticated visitors.  I can envisage that in the future this could be 
provided as a way for users to self-enroll (in courses for which that was 
configured as an option), although if that occurred I'd expect 
self-enrollment would be restricted to either institutionally authenticated 
users, or logged in LON-CAPA users.

>  
> localenroll.pm, sub instcode_format 
> Is this subroutine only used for the course catalog and could offer - depending on the code - dropdown-lists for 
> selecting the course(s) which should be displayed?  
>

This is used to generate dynamic dropdown lists based on a categorization of 
all institutional codes which exist for courses in the domain.  The lists 
are used in two slightly different ways in two places (a) course catalog; 
(b) help request form - click "Contact Helpdesk" link on log-in page, e.g., 
http://s10.lite.msu.edu/adm/helpdesk

>  
> Courses in course catalog 
> Is it correct, that filling in the institutional code is the only way to include a course in the course catalog 
> and leaving out the institutional code is the only way to exlcude a course from the course catalog? 
>  
> Guy wrote: 
>> To hide a course remove the insitutional code, to have a 
>> course display specify a code. 

Yes, as implemented at present the course catalog only displays courses with 
an institutional code.  To remove a course from the catalog you'd need to 
delete the institutional code. In the future, in moving from a simple 
colon-separated text string for each course's entry in the domain's 
nohist_courseids.db file for a domain to a more complex serilized perl data 
structure, a mechanism will be added to allow courses to be added or removed 
from the course catalog from a domain irrespective of institutional code. 

>  
> When is the catalog updated? I changed the institutional code, but the inst. code remained the same in the 
> course catalog. Also, deleting the inst. code in one course had no effect on the appeareance of this course in 
> the course catalog. 

The course catalog is built dynamically from the contents of 
nohist_courseids.db each time the page is called.  When a Domain Coordinator 
uses MCRS (Modify course settings) to delete an institutional code, 
nohist_courseids.db should be updated immediately.  If this did not occur, 
you might try using MCRS to add and then delete the code again, although it 
sounds as though you may have found a bug. 

>  
>  
> Old courses in course catalog 
> What is the reason for displaying old courses where no enrollment is anymore possible?  
>
At MSU, it is useful to be able to display courses from prior years and 
semesters so we can easily track when new courses adopt LON-CAPA, and rare 
instances when existing courses discontinue use.  If you were planning to 
use the course catalog as a gateway for self-enrollment then you might not 
want old courses to be displayed,  Other domain-based options could be added 
in the future to determine what courses appear in the catalog.  For the next 
release (2.4) I am expecting to work on interfaces for a variety of domain 
configuration options.
> 
>  
> "LON-CAPA section ID" 
> What is it? Where and how is it used?  
>
Students can be assigned to a section.  In LON-CAPA parameters can be set to 
apply to all users in a section.  A LON-CAPA section ID must be letters or 
digits.  In the context of auto-enrollment the idea is that you can map 
institutional sections to LON-CAPA section IDs. If you don't want to 
differentiate by section in your LON-CAPA course you'd leave the section ID 
textbox blank in ENRL -> Automated Enrollment -> Section Settings. A 
non-blank institutional section number is required, unless you indicate a 
crosslisting, in which case you would enter the complete institutional code 
as the crosslisting in ENRL -> Automated Enrollment -> Change crosslistings  
and leave the Section ID blank.

>  
> <authtype> 
> What is the correct content of <authtype> in the classlist data file, when we want the students to authenticate 
> a) via LDAP server ("Local Authentication") 
> b) LON-CAPA-internal ("Internally authenticated") 
> ?

Authentication is one of: krb4, krb5, int or loc
(a) loc
(b) int 

>  
> <startdate>, <enddate> 
> What format do these dates have? 

Format for startdate is YYYY:MM:DD:HH:MM:SS
Format forenddate is YYYY:MM:DD:HH:MM:SS

>  
> classlist data file 
> Even if I create such a file by hand and start Autoenroll.pl manually, it replies "No institutional classlist 
> data could be retrieved for 1P185967cc6c045d3fhwfl2". besides the "1" in sub run, I haven't changed or added 
> anything in localenroll.pm, because it seemed that the other routines are only for the course catalog or for 
> fetching data from the not exisiting course data server. 

At a minimum you'd also need to modify fetch_enrollment() so that 
$$replyref{$crs} is set to an integer greater than zero, and $okflag was 1.
You would also need to ensure that you have stored a course code ($instcode) 
for the course, and indicated at least one section number ($secnum) via ENRL 
 -> Automated Enrollment Manager -> Section Settings (unless using a 
crosslisting - see below). 

Your XML file should then be named:
fhwf_1P185967cc6c045d3fhwfl2_$instcode$secnum_classlist.xml 

If you wanted to use institutional codes without institutional sections. you 
would use ENRL -> Automated Enrollment Manager -> Change crosslistings to 
set up a crosslisted course, with $instcode as the crosslisting. 

Your XML file should then be named:
fhwf_1P185967cc6c045d3fhwfl2_$instcode_classlist.xml 

Whenever you have made changes to localenroll.pm you should restart 
loncontrol as both lond and lonsql call routines from localenroll.pm. 

Let me know if you have further questions. 

Stuart Raeburn
MSU LON-CAPA group 

>  
> Thank you in advance, 
> Stefan Bisitz 
>  
>   
> 
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin 
>