Subject: [LON-CAPA-dev] loncom /automation batchcreatecourse.pm

From: "H. K. Ng" <[email-masked]>
Date: Tue, 01 Mar 2005 08:05:31 -0500

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.
>
>

---

From: "Stuart Peter Raeburn" <[email-masked]>
Date: 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
>>> _______________________________________________
>>> LON-CAPA-dev mailing list
>>> [email-masked]
>>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev
>> 
>> _______________________________________________
>> LON-CAPA-dev mailing list
>> [email-masked]
>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev
> 
> _______________________________________________
> LON-CAPA-dev mailing list
> [email-masked]
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev 
>