[LON-CAPA-dev] loncom /automation batchcreatecourse.pm
Stuart Peter Raeburn
lon-capa-dev@mail.lon-capa.org
Mon, 14 Mar 2005 18:17:12 -0500
Hon Kie,
The course request form used at MSU requires the requestor to provide
additional information besides course name/number and sections.
There is also the ability to:
(a) Indicate (for multi-section courses) whether student enrollments should
be merged into a single course, or should be kept separate, or manipulated
using some combination of the two.
(b) Specify cross-listed course sections (for enrollment purposes).
(c) Specify start and end dates for auto-enrollment
(d) Specify default first and last access dates
(e) Specify additional instructional personnel and roles and sections
(f) Specify an existing course which should be cloned to create the new
course. Clonable courses are restricted to those in which the requestor of
the new course is either an active CC, or in which the requestor has been
listed as a cloner (can be set via PARM -> Course Parameters by a CC in the
course to be cloned).
The script then writes the required XML files ready for transfer to the
"pending" queue on the MSU LON-CAPA library server.
The intention has been to generalize the MSU course request form so it will
be suitable for other institutions and appropriate for inclusion in
LON-CAPA. This could be achieved by making use of routines defined in
localenroll.pm, or routines defined in a new localadmin.pm (which will be
customizable in the same way as the other local...pm modules).
A single web page for faculty to use to request creation of course shells in
one of a number of Learning Management systems supported at FSU certainly
makes sense. The issue is how to gather additional LON-CAPA specific
information (a to f above), once the instructor has authenticated and
selected a course via the universal FSU course request page. If the user is
directed to a subsidiary cgi script (or perl module) running on the FSU
LON-CAPA library server, some kind of unique token will be required to
verify that the requestor has been authenticated and has the authority to
request LON-CAPA course(s) for the specific class. If the
authentication/authorization web page uses cookies this will most likely
present problems as browsers are designed to prevent one site receiving
information about a cookie set by a site on a different server. (A unique
token in a query string - see below - might be better).
When you ask about the schedule for making the scripts available, I wonder
to which you scripts you refer. I expect that loncapafiles.lpml will be
modified in the near future so that a build of LON-CAPA from the latest CVS
version will add batchcreatecourse.pm and Autocreate.pl in their appropriate
places. Modification of /etc/cron.d/loncapa to include periodic execution of
Autocreate.pl may best be left as a local change for system administrators,
as there may be significant variation in how frequently different
institutions will prefer this process to run. If you are thinking of
scripts to generate an online request form, the timetable for this is less
clear. One approach is for me to generalize the existing MSU form, by
implementing the following processes as calls to routines in localenroll.pm
or localadmin.pm (which will be an institution-specific module similar to
localenroll.pm and localauth.pm):
localenroll::get_sections() - retrieve list of valid sections for a
particular course from institutional data source
localenroll::new_course() - confirm that requestor is a designated faculty
instructor for a particular course and section
localadmin::validate_user() - check authentication/authorization for a
requestor of a LON-CAPA course
localadmin::get_courses() - retreive list of courses for which a requestor
is a designated faculty instructor
For your situation at FSU, localadmin::validate_user() would need to
validate a token included in the request (most likely from the query string)
. Under this scenario, when a faculty instructor selects LON-CAPA course
creation from the central FSU course request page, redirection would occur
to a URL such as:
http://pollux.physics.fsu.edu/courserequest?tokenID=ASDG03423fgskd563iijsh
where courserequest points to the request form, and tokenID refers to a
unique token (of limited lifespan) set by the authenticating server that can
be used by the LON-CAPA library server to obbtain the requestor's username
and chosen course.
Within courserequest.pm a call would be made to localadmin::validate_user()
to check that the tokenID passed in was valid, and to obtain the uer's
information. If the token was invalid, or retrieval of the required data
failed in some other way, the user could be returned to a log-in page -- in
your case the central FSU course request page, but in other cases (e.g.,
MSU) a log-in page generated by courserequest.pm.
Some screenshots of the current form used at MSU can be found here:
http://loncapa.msu.edu/courserequests/
Stuart
H. K. Ng writes:
> Hi Stuart,
>
> I had a discussion with the person in charge of putting together the
> course request form for fsu and it looks like the scripts that you have
> written will work without any additional form. Basically, the intend is
> that regardless of which system an instructor chooses to use, he/she login
> to a common web site. Currently, the system automatically checks the user
> and then list the course(s)/sections the person is teaching. So all the
> front end work has already been done.
>
> So question: What is the schedule making the scripts available? I plan to
> start testing it over the summer.
>
> Thanks,
> -hk
>
>
>
>
>>> (b) A course request form (which includes authentication and
>>> authorization)
>>> generates the XML files containing course descriptions.
>>
>> Is there an existing form where one can try this out. Here at fsu, an
>> instructor requests a course from a well established web-site. Currently,
>> the instructor has the option to request a BB course or a web-MC course.
>> I like to have lon-capa added as one of the option. Now since the
>> instructor has to sign in to get to this request form, the username and
>> course or courses he/she is teaching will then be passed on to the
>> lon-capa course request form. If this form resides on the library server,
>> then the course info can be saved directly to
>> /home/httpd/perl/tmp/addcourse/$dom/pending after which the Autocreate.pl
>> can take over.
>>
>> -hk
>>
>>
>>>> Hi Stuart,
>>>> A while back you committed the following on cvs. Is there a way I can
>>>> try this out? I like to see what I need to do on my end to tie it to
>>>> the fsu course request form.
>>>
>>>> Thanks,
>>>> -hk
>>>> At 10:37 AM 1/30/2005, you wrote:
>>>>> raeburn Sun Jan 30 10:37:03 2005 EDT
>>>>> Added files:
>>>>> /loncom/automation batchcreatecourse.pm
>>>>> Log:
>>>>> Collection of routines for batch creation of courses from file(s)
>>>>> containing XML description of courses. Intended to be called from
>>>>> command line script, or from a web page by a Domain Coordinator.
>>>
>>>
>>> _______________________________________________
>>> LON-CAPA-dev mailing list
>>> LON-CAPA-dev@mail.lon-capa.org
>>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev
>>
>> _______________________________________________
>> LON-CAPA-dev mailing list
>> LON-CAPA-dev@mail.lon-capa.org
>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev
>
> _______________________________________________
> LON-CAPA-dev mailing list
> LON-CAPA-dev@mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev
>