[LON-CAPA-admin] auto-enrollment again
Stuart Peter Raeburn
raeburn at msu.edu
Fri Jan 13 09:37:14 EST 2006
Peter,
The piece that needs to be customized for your institution is a
fetch_enrollment() routine that will put XML files containing enrollment
data in /home/httpd/perl/tmp/
with file names such as:
gwu_134512831e340c5gwul1_ss06phy142201_classlist.xml
where gwu is the domain of the course, 134512831e340c5gwul1 is the course
name, and ss06phy142201 is an institutional course code for a section which
maps to this particular LON-CAPA course. There could be several of these
files for a single LON-CAPA course, if the course has multiple sections.
Files stored in /home/httpd/perl/tmp/ are deleted each time after the
automated enrollment process has occurred.
If you do not have access to a datastore which you can query for enrollment
data, but instead will be using CSV files, then your implementation would
most likely involve uploading the CSV files to some (permanent) directory on
the file system on a regular basis.
A fetch_enrollment() routine would then be crafted to convert the contents
of the CSV files to XML and to write the output to appropriately named files
in /home/httpd/perl/tmp/. fetch_enrollment() is called whenever
auto-enrollment needs to occur, either for a single course as prompted via
Course Coordinator action via ENRL -> Automated Enrollment Manager ->
"Update Roster Now", or for a number of courses when
/home/httpd/perl/Autoenroll.pl is called by the last entry in
/etc/cron.d/loncapa
A decision needs to be made about the format of the course code. In general
you will need to adopt a format that provides for a unique code for each
course section in your system (e.g., a course code of ss06phy142), with
section numbers such as 001, 002 etc. used for the different sections.
If you wish to use the dynamic select boxes to gather information from
students submitting help requests via the "Ask Helpdesk" form on the log-in
page you will want to provide a means of extracting information about the
identity of the course from the course code. There are two general
approaches - either you maintain a look-up table that does this for you, or
you adopt a format that can be broken into its constituent parts (year,
semester or term, department, course number) via a perl regular expression.
LON-CAPA places a few constraints on the format of the course code. The
following : , are not allowed in the course code as they are used as
separators for storage of multiple sections or crosslistings. This could
change in the future by use of escapes, but for now the best strategy might
be to restrict characters used in your course codes to letters, numbers and
underscores.
Once you have established the format you will use for the course code, as DC
yu can use MCRS to associate course codes with courses, and ENRL ->
Automated Enrollment Manager to associate section numbers and/or
crosslistings with courses (and identify the desired GWU section -> LON-CAPA
section mapping).
Some more informattion about setting up auto-enrollment when enrollment data
is stored in a directory, and retrieved from there rather than via a query
to a data store can be found at:
http://mail.lon-capa.org/pipermail/lon-capa-admin/2004-October/000721.html
I can provide assistance if you decide to move forward with this, and could
put together a CSV-to-XML conversion routine in perl. To generalize this,
it would probably be useful to provide an interface so that a DC could
define a default mapping of columns to attributes. This might be one of a
number of categories of domain-wide data that we might start to store on the
primary library server for a domain (a concept introduced in LON-CAPA 2.1 in
the context of the MAIL function accessible to Domain Coordinators).
This same applies if you decided to simply use the "Upload Classlist"
function currently in ENRL (rather than implement auto-enrollment) - it
would be useful if we could provide a means for a DC to define a default
arrangement columns in uploaded CSV data to avoid the need for the user to
select them each time they used upload claslist to a new course. Of course
by going this route instead of auto-enrollment you do miss out out on the
benefits of auto-dropping of students who are officially no longer
registered for a class.
If you prefer, feel free to contact me directly (offlist) if you have
specific questions relating to implementation at GWU that need to be
addressed.
Stuart
Stuart Raeburn
Div. Science & Math Education
Michigan State University
East Lansing MI 48824
Peter Kovac writes:
> Hello again. Per Guy's suggestion, I took a look through the comments
> in /home/httpd/lib/perl/localenroll-std.pm My perl is a bit rusty (been a
> few years) and, to be honest, tends to be more hacks than pretty code so I
> apologize if I seem dense.
>
> First, my eventual goal. I have been completely unsuccessful at
> getting access to a proper enrollment datastore. However, our faculty can
> easily produce classlists in tabular (CVS/Excel) format. I'd like to hack
> together something that will convert uploaded classlist tables into proper
> XML and insert them into the auto-enrollment system. I will, of course,
> pass on said ugly hack to whomever wants it.
>
> I gather that fetch_enrollment is designed to generate XML files that
> are then imported as class lists by other parts of the system. My reading
> of the perl seems to indicate that the actual work is done by code
> somewhere other than /home/httpd/lib/perl/localenroll-std.pm or that I'm
> supposed to write the interface between the enrollment and our data source
> (vaguely recall something like that said at a conference).
>
> So, any suggestions for other places to look to get a better handle on
> the enrollment framework? Other advice?
>
> Thanks,
> Peter
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>
More information about the LON-CAPA-admin
mailing list