[LON-CAPA-admin] Batch creation

[Neubauer, Paul]

Hi Stuart,

Thank you for your excellent answers to my questions.

So, to summarize, it appears that your current recommendation is (at least for cases (like ours) where we want to create a relatively small and not completely predictable set of courses for inclusion in LON-CAPA) that it is probably best to create the courses interactively within LON-CAPA rather than trying to generate XML files somewhere else for batch creation of the courses. Is that right?

We have not previously been using an autoenrollment procedure, but we want to move to doing that. We have also determined that we want to authenticate using Shibboleth (which we are currently using for other purposes anyway).

I'd like to try to restate what I think we need to do so you can tell how well or poorly I understand the problems. 

For the Shibboleth part, do we modify localauth.pm? The Domain Coordination Tutorial And Manual at http://lon-capa.bsu.edu/adm/help/domain.manual.pdf has an example for LDAP that appears to take a username and password as parameters and then requests authentication from the LDAP server. However as I (poorly) understand it, Shibboleth has a different model where the user is redirected to the Shibboleth ID server where authentication is performed, so that lon-capa never even sees the password, and which then hands off suitable authentication tokens to the LON-CAPA server. If I more or less failed to garble that too badly, is localauth.pm the proper place to make the mods? If so, what do the mods look like? Also, what tokens does the Shibboleth server need to return for a successful (or unsuccessful) login?

Regarding autoenrollment, I'll try to refer to the example in localenroll.pm for my questions. 

First: fetch_enrollment requires three arguments. The domain appears to be obvious: "msu" for Michigan State courses, "bsu" for Ball State courses. The "course" is less obvious. The example has COURSE = 43551dedcd43febmsul1 and INSTITUTIONALCODE = fs03nop590001. I am guessing that 43551dedcd43febmsul1 is a key that is internal to the specific LON-CAPA installation whereas fs03nop590001 is a course code that keys into larger MSU data outside of LON-CAPA. Is this correct?

I'm guessing that the last 5 characters "msul1" is the name of the MSU library server. But what is the rest and where do I find it? Is this a standard kind of name that is generated automatically when a course is created or is it simply the name entered by the person creating the course? For example, when I look at a list of courses here, I find a table listing:

Select	Course Title	Domain	Course Code	Owner/Co-owner(s)

and when I select a course, I get a page that says something like:
View/Modify settings for: ASTRO 120 Spring Semester 2012
I have not yet found anything that looks remotely like "43551dedcd43febmsul1" among the settings that I can view or modify. Does this imply that we should not be naming courses things like "ASTRO 120 Spring Semester 2012" or is the 43551dedcd43febmsul1 something else (and where would I find it)? Does the course "name" need to be free of spaces and underscores?

For the "institutionalcode", is there anything I need to know? It appears that MSU uses a nice, predictable, descriptive code with no internal "_"s or spaces, but I'm not sure that we have anything quite so convenient. We could generate something similar, I suppose by parsing a string like fs03nop590001 and using the result in a database query, or sh/could we just use a database key like "327652"? Our actual LON-CAPA users wouldn't have a convenient way of discovering that kind of course key, but I suppose I could supply it. I imagine the alternative would be to require course requesters to assign something suitable (like your format) in the "Course Code" box.

Most likely, policy from above will be that we not be able to connect directly to the database and will have to communicate with it by means of sftp to put lists of courses and get lists of students. I forsee a likely scenario where we have an intermediate system (call it Int) where database queries can be run on a schedule, so the sequence might be something like:
* a scheduled process on lon-capa.bsu.edu gets list of courses and sends to Int
* Int reads course list and creates:
	- list of sections (for the get_sections sub)
	- list of students in course
	- drop data? 
* fetch_enrollment() 
	- gets data files from Int 
	- creates classlist files 
	- returns file specs and class sizes back to whatever calls it

Does that sound like a sensible arrangement? What does call fetch_enrollment, BTW? I will have to look at that to figure out what courses exist and need to be updated.

On the subject of updates, the manual (p.13) says 
"The auto-enrollment process will update user information (name, e-mail address, studentID etc.) for any student who is being added to the course, but will not change it in other case (i.e., drops, section switches) should there be a difference between the values in the institutional roster and the values in the LON-CAPA classlist. To change user information for students already in the course, the Auto-update process must be run"

The manual (p.9) lists several settings for auto_update. Where are those settings defined?

On the same page, it also says "In order for Autoupdate to work, the &allusers_info() routine in localenroll.pm needs to be customized and a conduit established to institutional data." I do not find any allusers_info routine in localenroll.pm. Do I need to create one? Is there any documentation on what it needs to do, comparable to what fetch_enrollment does? Does allusers_info run during fetch_enrollment? Otherwise something (fetch_enrollment?) deletes the *classlist.xml files.

BTW, what would the <authtype> look like if we use Shibboleth? The example in localenroll.pm is "<authtype>krb4</authtype>"

I'm sure I will have other questions along the way, and I suppose I could ask them off-list, but I thought it might be a good idea to have a reasonable portion of the discussion on-list so that other people who may have similar questions in the future might be able to find the answers.

Thanks,
Paul