Annotation of loncom/enrollment/localenroll.pm, revision 1.54
1.5 albertel 1: # functions to glue school database system into Lon-CAPA for
2: # automated enrollment
1.54 ! raeburn 3: # $Id: localenroll.pm,v 1.53 2015/08/05 18:47:17 raeburn Exp $
1.5 albertel 4: #
5: # Copyright Michigan State University Board of Trustees
6: #
7: # This file is part of the LearningOnline Network with CAPA (LON-CAPA).
8: #
9: # LON-CAPA is free software; you can redistribute it and/or modify
10: # it under the terms of the GNU General Public License as published by
11: # the Free Software Foundation; either version 2 of the License, or
12: # (at your option) any later version.
13: #
14: # LON-CAPA is distributed in the hope that it will be useful,
15: # but WITHOUT ANY WARRANTY; without even the implied warranty of
16: # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17: # GNU General Public License for more details.
18: #
19: # You should have received a copy of the GNU General Public License
20: # along with LON-CAPA; if not, write to the Free Software
21: # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
22: #
23: # /home/httpd/html/adm/gpl.txt
24: #
25: # http://www.lon-capa.org/
26: #
1.32 jms 27:
28: =pod
29:
30: =head1 NAME
31:
32: localenroll
33:
34: =head1 SYNOPSIS
35:
36: This is part of the LearningOnline Network with CAPA project
37: described at http://www.lon-capa.org.
38:
39:
40: =head1 NOTABLE SUBROUTINES
41:
42: =over
43:
44: =cut
45:
1.4 raeburn 46: package localenroll;
47:
48: use strict;
1.6 albertel 49:
1.32 jms 50: =pod
51:
52: =item run()
53: set this to return 1 if you want the auto enrollment to run
54:
55: Beginning with LON-CAPA version 2.4, use of this routine is
56: deprecated. Whether or not Autoenroll.pl should run is set
57: by the Domain Coordinator via "Set domain configuration",
58: provided in the Domain Management section of the Main menu.
59:
60: =cut
1.6 albertel 61:
1.9 raeburn 62: sub run() {
63: my $dom = shift;
64: return 0;
65: }
1.4 raeburn 66:
1.32 jms 67:
68: =pod
69:
70: =item fetch_enrollment()
71:
72: connects to the institutional classlist data source,
73: reads classlist data and stores in an XML file
74: in /home/httpd/perl/tmp/
75:
76: classlist files are named as follows:
77:
78: DOMAIN_COURSE_INSTITUTIONALCODE_classlist.xml
79:
80: e.g., msu_43551dedcd43febmsul1_fs03nop590001_classlist.xml
81: where DOMAIN = msu COURSE = 43551dedcd43febmsul1
82: INSTITUTIONALCODE = fs03nop590001
83: (MSU's course naming scheme - fs03 = Fall semester 2003, nop =
84: department name, 590 = course number, 001 = section number.)
85:
86: fetch_enrollment requires three arguments -
87: $dom - DOMAIN e.g., msu
88: $affiliatesref - a reference to a hash of arrays that contains LON-CAPA
89: courses that are to be updated as keys, and institutional coursecodes
90: contributing enrollment to that LON-CAPA course as elements in each array.
91: $replyref - a reference to a hash that contains LON-CAPA courses
92: that are to be updated as keys, and the total enrollment count in all
93: affiliated sections, as determined from institutional data as hash elements.
94:
95: As an example, if fetch_enrollment is called to retrieve institutional
96: classlists for a single LON-CAPA course - 43551dedcd43febmsul1 which
97: corresponds to fs03nop590, sections 001, 601 and 602 , and the course
98: also accommodates enrollment from a crosslisted course in the ost
99: department - fs03ost580002:
100:
101: the affiliatesref would be a reference to %affiliates which would be:
102:
103: @{$affiliates{'43551dedcd43febmsul1'}} =
104: ("fs03nop590001","fs03nop590601","fs03nop590602","fs03ost580002");
105:
106: fetch_enrollment would create four files in /home/httpd/perl/tmp/.
107: msu_43551dedcd43febmsul1_fs03nop590001_classlist.xml
108: msu_43551dedcd43febmsul1_fs03nop590601_classlist.xml
109: msu_43551dedcd43febmsul1_fs03nop590602_classlist.xml
110: msu_43551dedcd43febmsul1_fs03ost580002_classlist.xml
111:
112: In each file, student data would be stored in the following format
113:
114: <student username="smith">
115: <autharg>MSU.EDU</autharg>
116: <authtype>krb4</authtype>
117: <email>smith@msu.edu</email>
118: <enddate></enddate>
119: <firstname>John</firstname>
120: <generation>II</generation>
121: <groupID>fs03nop590001</groupID>
122: <lastname>Smith</lastname>
123: <middlename>D</middlename>
124: <startdate></startdate>
125: <studentID>A12345678</studentID>
1.44 raeburn 126: <credits></credits>
127: <inststatus></inststatus>
1.32 jms 128: </student>
129:
130: with the following at the top of the file
131: <?xml version="1.0" encoding="UTF-8"?>
132: <!DOCTYPE text>
133: <students>
134:
135: (all comment - s removed)
136:
137: and a closing:
138: </students>
139:
140: The <startdate> and the <enddate> are the activation date and expiration date
141: for this student's role. If they are absent, then the default access start and
142: default access end dates are used. The default access dates can be set when
143: the course is created, and can be modified using the Automated Enrollment
144: Manager, or via the 'Upload a class list','Enroll a single student' or
145: 'Modify student data' utilities in the Enrollment Manager, by checking the
146: 'make these dates the default for future enrollment' checkbox. If no default
147: dates have been set, then the tudent role will be active immediately, and will
148: remain active until the role is explicitly expired using ENRL -> Drop students.
149: If dates are to included in the XML file, they should be in the format
150: YYYY:MM:DD:HH:MM:SS (: separators required).
151:
1.44 raeburn 152: The <credits> tag need only be used if the credits earned by the students will
153: be different from the default for the course. The course default is set when the
154: course is created and can be modifed by a Domain Coordinator via "View or
1.50 raeburn 155: modify a course or community" on the DC's Main Menu screen.
1.44 raeburn 156:
157: A value for <inststatus> should be the institutional status used for students,
1.50 raeburn 158: and should be one of the types defined in the "Institutional user types"
159: section in the domain config screen for:
160: "Default authentication/language/timezone/portal/types"
161:
162: If no status types are defined for the domain this tag can be omitted.
163: If Autoupdate.pl is enabled in your domain, updates to the institutional
164: status set here will be updated by Autoupdate.pl, should changes occur.
1.44 raeburn 165:
1.32 jms 166: If there were 10 students in fs03nop590001, 5 students in fs03nop59o601,
167: 8 students in fs03nop590602, and 2 students in fs03ost580002,
168: then $$reply{'43551dedcd43febmsul1'} = 25
169:
170: The purpose of the %reply hash is to detect cases where the institutional
171: enrollment is 0 (most likely due to a problem with the data source).
172: In such a case, the LON-CAPA course roster is left unchanged (i.e., no
173: students are expired, even if automated drops is enabled.
174:
175: fetch_enrollment should return a 0 or 1, depending on whether a connection
176: could be established to the institutional data source.
177: 0 is returned if no connection could be made.
178: 1 is returned if connection was successful
179:
180: A return of 1 is required for the calling modules to perform LON-CAPA
181: roster changes based on the contents of the XML classlist file(s), e,g,,
182: msu_43551dedcd43febmsul1_fs03nop590001_classlist.xml
183:
184: XML classlist files are temporary. They are deleted after the enrollment
185: update process in the calling module is complete.
186:
187:
188: =cut
1.1 raeburn 189:
190: sub fetch_enrollment {
1.7 matthew 191: my ($dom,$affiliatesref,$replyref) = @_;
192: foreach my $crs (sort keys %{$affiliatesref}) {
193: $$replyref{$crs} = 0;
194: }
195: my $okflag = 0;
196: return $okflag;
1.4 raeburn 197: }
198:
1.32 jms 199: =pod
200:
201: =item get_sections()
202:
203: This is called by the Automated Enrollment Manager interface
204: (lonpopulate.pm) to create an array of valid sections for
205: a specific institutional coursecode.
206: e.g., for MSU coursecode: fs03nop590
207: ("001","601","602") would be returned
208:
209: If the array returned contains at least one element, then
210: the interface offerred to the course coordinator, lists
211: official sections and provides a checkbox to use to
212: select enrollment in the LON-CAPA course from each official section.
213:
214: get_sections takes two arguments - (a) the institutional coursecode
215: (in the MSU case this is a concatenation of semester code, department
216: and course number), and (b) the LON-CAPA domain that contains the course.
217:
218: If there is no access to official course sections at your institution,
219: then an empty array is returned, and the Automated Enrollment Manager
220: interface will allow the course coordinator to enter section numbers
221: in text boxes.
222:
223:
224:
225: =cut
1.4 raeburn 226:
227: sub get_sections {
1.9 raeburn 228: my ($coursecode,$dom) = @_;
1.4 raeburn 229: my @secs = ();
230: return @secs;
1.1 raeburn 231: }
232:
1.32 jms 233: =pod
234:
235: =item new_course()
236:
237: This is called by loncreatecourse.pm and
238: lonpopulate.pm to record that fact that a new course section
239: has been added to LON-CAPA that requires access to institutional data
240: At MSU, this is required, as institutional classlists can only made
241: available to faculty who are officially assigned to a course.
242:
243: The new_course subroutine is used to check that the course owner
244: of the LON-CAPA course is permitted to access the institutional
245: classlist for any course sections and crosslisted classes that
246: the course coordinator wishes to have affiliated with the course.
247:
248: If access is permitted, then 'ok' is returned.
249: The course section or crosslisted course will only be added to the list of
250: affiliates if 'ok' is returned.
251:
1.41 raeburn 252: new_course takes three required arguments -
1.32 jms 253: (a) the institutional courseID (in the MSU case this is a concatenation of
254: semester code, department code, course number, and section number
255: e.g., fs03nop590001).
256: (b) the course owner. This is the LON-CAPA username and domain of the course
257: coordinator assigned to the course when it is first created, in the form
258: username:domain
259: (c) the LON-CAPA domain that contains the course
260:
1.41 raeburn 261: new_course also takes a fourth (optional) argument -
262: (d) the course co-owners, as a comma-separated list of username:domain for
263: any co-owners.
264:
1.32 jms 265: =cut
1.4 raeburn 266:
267: sub new_course {
1.41 raeburn 268: my ($course_id,$owner,$dom,$coowners) = @_;
1.4 raeburn 269: my $outcome = 'ok';
270: return $outcome;
1.1 raeburn 271: }
272:
1.32 jms 273: =pod
274:
275: =item validate_courseID()
276:
277: This is called whenever a new course section or crosslisted course
278: is being affiliated with a LON-CAPA course (i.e., by loncreatecourse.pm
279: and the Automated Enrollment Manager in lonpopulate.pm).
280: A check is made that the courseID that the course coordinator wishes
281: to affiliate with the course is valid according to the institutional
282: schedule of official classes
283:
284: A valid courseID is confirmed by returning 'ok'
285:
286: validate_courseID takes two arguments -
287: (a) the institutional courseID (in the MSU case this is a concatenation of
288: semester code, department code, course number, and section number
289: e.g., fs03nop590001).
290: (b) the LON-CAPA domain that contains the course
291:
292: =cut
1.4 raeburn 293:
294: sub validate_courseID {
1.9 raeburn 295: my ($course_id,$dom) = @_;
1.4 raeburn 296: my $outcome = 'ok';
297: return $outcome;
298: }
1.1 raeburn 299:
1.32 jms 300: =pod
301:
1.36 raeburn 302: =item validate_instcode()
303:
304: This is called when a request is being made for an official course.
305: A check is made that the institutional code for which a course is
306: is being requested is valid according to the institutional
307: schedule of official classes.
308:
309: If the username of the course owner is provided, a more restrictive
310: test is used, namely that the requestor is listed as instructor of
311: record for the course in the institution's course schedule/database.
312:
1.38 raeburn 313: validate_instcode takes three arguments -
1.36 raeburn 314: (a) the LON-CAPA domain that will contain the course
315: (b) the institutional code (in the MSU case this is a concatenation of
316: semester code, department code, and course number, e.g., fs03nop590.
317: (c) an optional institutional username for the course owner.
318:
1.39 raeburn 319: An array is returned containing (a) the result of the check for a valid
1.44 raeburn 320: instcode, (b) an (optional) course description, and (c) the default credits
321: earned by students when completing this course. If no institutional credits
322: value is available, the default credits for the course can be set via the
323: course request form, or via XML in a batch file, of via the web form used
324: by the Domain Coordinator to create new courses one at a time.
325:
1.39 raeburn 326: A valid instcode is confirmed by returning 'valid'.
1.44 raeburn 327:
1.39 raeburn 328: If no course description is available, '' should be set as
329: the value of the second item in the returned array.
330:
1.36 raeburn 331: =cut
332:
333: sub validate_instcode {
1.38 raeburn 334: my ($dom,$instcode,$owner) = @_;
1.36 raeburn 335: my $outcome = '';
1.39 raeburn 336: my $description = '';
1.44 raeburn 337: my $credits = '';
338: return ($outcome,$description,$credits);
1.36 raeburn 339: }
340:
341: =pod
342:
1.38 raeburn 343: =item validate_crsreq()
344:
345: This is used to check whether a course request should be processed
346: automatically, or held in a queue pending administrative action at
347: the institution.
348:
349: Course requests will trigger this check if the process type has been set
1.54 ! raeburn 350: to 'validate' for the course type (official, unofficial, textbook,
! 351: placement or community) and the requestor's affiliation. Whether
! 352: "validate" is an available option in the Domain Configuration menu
! 353: is controlled by auto_courserequest_checks().
1.38 raeburn 354: One scenario is where the request is for an official course, in which case
355: a check could be made that the requestor is listed as instructor of
356: record for the course in the institution's course schedule/database.
357:
358: Other scenarios are possible, and the routine can be customized according
359: to whatever rules a domain wishes to implement to run validations against
360: given the data passed in to the routine.
361:
1.51 raeburn 362: validate_crsreq takes seven arguments -
1.38 raeburn 363: (a) the LON-CAPA domain that will contain the course.
364: (b) the username:domain for the course owner.
1.54 ! raeburn 365: (c) the course type (official, unofficial,textbook, placement or community)
1.38 raeburn 366: (d) a comma-separated list of institutional affiliations of
367: the course owner.
368: (e) the institutional code (in the MSU case this is a concatenation of
1.46 raeburn 369: semester code, department code, and course number, e.g., fs03nop590).
1.38 raeburn 370: (f) a comma-separated list of institutional sections included in
371: the course request (only applicable to official courses).
1.46 raeburn 372: (g) an optional reference to a hash of custom form data.
1.52 raeburn 373: The custom form data will come from crsreq_updates(), with one
374: additional item: $custominfo->{'_LC_clonefrom'}, provided internally
375: (the courseID of the LON-CAPA course being cloned).
1.38 raeburn 376:
377: A valid courserequest is confirmed by returning 'process'.
1.46 raeburn 378: The following can be returned: process, rejected, pending, approval or
379: error (with error condition - no :), followed by a : and then an optional message.
1.38 raeburn 380:
381: (a) process - the requestor is the recorded instructor - create the course
1.52 raeburn 382:
1.40 raeburn 383: (b) rejected - the requestor should never be requesting this course, reject the
1.38 raeburn 384: request permanently
1.52 raeburn 385:
1.38 raeburn 386: (c) pending - the requestor is not the recorded instructor, but could
387: become so after administrative action at the institution. Put the
1.46 raeburn 388: request in a queue and, if an official course, check
389: localenroll:validate_instcode() periodically until the status changes to
390: "valid".
1.52 raeburn 391:
1.38 raeburn 392: (d) approval - the request will be held pending review by a Domain Coordinator.
1.52 raeburn 393:
1.38 raeburn 394: (e) error (followed by the error condition).
395:
396: =cut
397:
398: sub validate_crsreq {
1.46 raeburn 399: my ($dom,$owner,$crstype,$inststatuslist,$instcode,$instseclist,$custominfo) = @_;
1.38 raeburn 400: my $outcome = 'approval';
401: return $outcome;
402: }
403:
404: =pod
405:
406: =item crsreq_checks()
407:
408: This is used to determine whether the "validate" option should appear in the
409: possible choices for course request processing in the Domain Configuration
410: menu for Course Requests. Ultimately it is called by domainprefs.pm (via:
411: lonnet -> lond -> localenroll.pm) The domain configuration menu includes
1.54 ! raeburn 412: a table where columns are course type (official, unofficial, textbook,
! 413: placement or community) and rows are institutional affiliations
! 414: (e.g., Faculty, Staff, Student etc.).
1.38 raeburn 415:
1.42 raeburn 416: crsreq_checks() takes three arguments: $dom, $reqtypes, $validations.
1.38 raeburn 417: $dom - the domain for which validation options are needed.
418: $reqtypes - ref to an ARRAY of course types (i.e., official, unofficial and community.
419: $validations - ref to a hash of a hash which will determine whether "validate"
420: will be one of the possible choices for each course type (outer hash key),
421: and institutional type (inner hash key).
422:
423: For example to allow validate to be a choice for official classes for Faculty,
424: req_checks would include:
425:
426: $validations{'official'}{'Faculty'} = 1;
427:
428: This routine is closely tied to validate_crsreq(). "Validate" should not be
429: a possible choice in the domain configuration menu for a particular course
430: type/institutional affiliation, unless a corresponding validation code has
431: been implemented in validate_crsreq().
432:
433: For example at MSU, official courses requested by Faculty will be validated
434: against the official schedule of classes to check that the requestor is one
435: of the instructors of record for the course. In this case validate_crsreq()
436: includes a call to validate_instcode().
437:
438: =cut
439:
440: sub crsreq_checks {
441: my ($dom,$reqtypes,$validations) = @_;
442: if ((ref($reqtypes) eq 'ARRAY') && (ref($validations) eq 'HASH')) {
443: my (%usertypes,@order);
444: if (&inst_usertypes($dom,\%usertypes,\@order) eq 'ok') {
445: foreach my $type (@{$reqtypes}) {
446: foreach my $inst_type (@order) {
447: $validations->{$type}{$inst_type} = 0;
448: }
449: }
450: }
451: }
452: return 'ok';
453: }
454:
1.52 raeburn 455: =pod
456:
457: =item crsreq_updates()
458:
459: This is used to customize the LON-CAPA course request process.
460: There are two hash references: $incoming, and $outgoing; $incoming can
461: contain additional information collected from the requester, whereas $outgoing
462: can contain custom items to send back to lonrequestcourse.pm, which creates the
463: HTML displayed to the user during a course request.
464:
465: Different key-value pairs may be returned to lonrequestcourse.pm in the $outgoing
466: hashref depending on the current action. The available actions are:
467: review, prevalidate, process, created and queued.
468:
469: One scenario would be to return HTML markup in: $outgoing->{'reviewweb'},
470: i.e., where the action is 'review', to prompt the user to provide additional
471: information as part of the course request, at the request review stage,
472: (i.e,, the page which contains the button used to submit a completed course request).
473:
474: The HTML could contain form elements (e.g., radio buttons etc.). The value(s)
475: selected by the requester in those form elements will be available in the incoming
476: hashref, for a subsequent action, if the corresponding keys have been included
477: in $outgoing->{'formitems'}, i.e., $outgoing will be hash of a hash. If a
478: particular form item will the single valued, the value set for the key in the
479: inner hash in $outgoing should be 1, otherwise, if it will be multi-valued,
480: the value should be multiple.
481:
482: The $outgoing hashref can contain a 'formitems' key for both the prevalidate
483: and process actions, as calls to localenroll::crsreq_update() can originate
484: in lonrequestcourse::process_request() for both of those actions.
485:
486: The retrieved form values are passed to localenroll::validate_crsreq() as the
487: optional seventh arg (a hashref) -- $custominfo.
488:
489: =cut
490:
1.45 raeburn 491: sub crsreq_updates {
492: my ($cdom,$cnum,$crstype,$action,$ownername,$ownerdomain,$fullname,$title,
1.47 raeburn 493: $code,$accessstart,$accessend,$incoming,$outgoing) = @_;
1.45 raeburn 494: unless (ref($outgoing) eq 'HASH') {
495: return 'fail';
496: }
497: my %extrainfo;
498: if (ref($incoming) eq 'HASH') {
499: %extrainfo = %{$incoming};
500: }
501: if ($action eq 'review') {
502: $outgoing->{'reviewweb'} = '';
1.46 raeburn 503: } elsif ($action eq 'prevalidate') {
504: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name
505: # and value is multiple, if there
506: # are multiple form elements with
507: # the same name.
1.45 raeburn 508: } elsif ($action eq 'process') {
509: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name
510: # and value is multiple, if there
511: # are multiple form elements with
1.46 raeburn 512: # the same name.
1.45 raeburn 513: } elsif ($action eq 'created') {
514: $outgoing->{'createdweb'} = '';
515: $outgoing->{'createdmsg'} = [{
516: mt => '',
517: args => [],
518: }];
1.48 raeburn 519: $outgoing->{'createdactions'} = {
520: environment => {},
521: };
522: # environment can contain key=>value for
523: # items to set in the course environment.
524: # These would be items which are NOT included
525: # in the items set via options in the course
526: # request form. Currently self-enrollment
527: # settings are the only ones allowed, i.e.,
528: # internal.selfenroll_types internal.selfenroll_registered
529: # internal.selfenroll_section internal.selfenroll_start_access
530: # internal.selfenroll_end_access internal.selfenroll_limit
531: # internal.selfenroll_cap internal.selfenroll_approval
532: # internal.selfenroll_notifylist
1.45 raeburn 533: } elsif ($action eq 'queued') {
1.46 raeburn 534: $outgoing->{'queuedmsg'} = [{
535: mt => '',
1.45 raeburn 536: args => [],
537: }];
538: $outgoing->{'queuedweb'} = '';
539: }
540: return 'ok'
541: }
542:
1.38 raeburn 543: =pod
544:
1.32 jms 545: =item create_password()
546:
547: This is called when the authentication method set for the automated
548: enrollment process when enrolling new users in the domain is "localauth".
549: This could be signalled for the specific user by the value of localauth
550: for the <authtype> tag from the classlist.xml files, or if this is blank,
551: the default authtype, set by the domain coordinator when creating the course
552: with loncreatecourse.pm.
553:
554: create_password takes three arguments -
555: (a) $authparam - the value of <autharg> from the classlist.xml files,
556: or if this blank, the default autharg, set by the domain coordinator when
557: creating the course with loncreatecourse.pm
558: (b) $dom - the domain of the new user.
559: (c) $username - the username of the new user (currently not actually used)
560:
561: Four values are returned:
562: (a) the value of $authparam - which might have been changed
563: (b) a flag to indicate whether a password had been created
564: 0 means no password created
565: 1 means password created. In this case the calling module - Enrollment.pm
566: will send the LON-CAPA username and password to the new user's e-mail
567: (if one was provided), or to the course owner (if one was not provided and
568: the new user was created by the automated process), or to the active
569: course coordinator (if the new user was created using the 'update roster
570: now' interface included in the Automated Enrollment Manager).
571: (c) a flag to indicate that the authentication method is correct - 'ok'.
572: If $authchk is not set to 'ok' then account creation and enrollment of the
573: new user will not occur.
574: (d) if a password was created it can be sent along. This is the password
575: which will be included in the e-mail sent to the new user, or made available
576: to the course owner/course coordinator if no e-mail address is provided. If
577: you do not wish to send a password, but want to give instructions on obtaining
578: one, you could set $newpasswd as those instructions. (e.g.,
579: $newpasswd = '(Please visit room 212, ACNS Bldg. to obtain your password)';
580: The value of $newpasswd is NOT written in the user's LON-CAPA passwd file in
581: /home/httpd/lonUsers/$dom/a/b/c/abcuser/passwd, which in the case of a user
582: employing localauth will contain 'localauth:$authparam'. If you need to include
583: a parameter in the user's passwd file, you should return it as $authparam,
584: i.e., the first of the variables returned by create_password().
585:
586:
587: =cut
1.4 raeburn 588:
589: sub create_password {
1.13 albertel 590: my ($authparam,$dom,$username) = @_;
1.4 raeburn 591: my $authchk = 'ok';
1.11 raeburn 592: my $newpasswd = '';
1.4 raeburn 593: my $create_passwd = 0;
1.11 raeburn 594: return ($authparam,$create_passwd,$authchk,$newpasswd);
1.1 raeburn 595: }
596:
1.32 jms 597: =pod
598:
599: =item instcode_format()
600:
601: Split coursecodes into constituent parts.
602: e.g., INSTITUTIONALCODE = fs03nop590, LON-CAPA COURSEID: 43551dedcd43febmsul1
603: (MSU's course naming scheme - fs03 = Fall semester 2003, nop =
604: department name, 590 = course number)
605:
606: Incoming data:
607: $dom (domain)
608: $$instcodes{'43551dedcd43febmsul1'} = 'fs03nop590' (hash of courseIDs)
609:
610: fs03nop590 would be split as follows
611: @{$codetitles} = ("year","semester","department","number")
1.33 bisitz 612: $$codes{'year'} = '2003'
1.32 jms 613: $$codes{'semester'} = 'Fall'
614: $$codes{'department'} = 'nop'
615: $$codes{'number'} = '590'
616:
617: requires six arguments:
618: domain ($dom)
619: reference to hash of institutional course IDs ($instcodes)
620: reference to hash of codes ($codes)
621: reference to array of titles ($codetitles)
622: reference to hash of abbreviations used in categories
623: reference to hash of arrays specifying sort order used in category titles
624:
625: e.g., %{$$cat_titles{'Semester'}} = (
626: fs => 'Fall',
627: ss => 'Spring',
628: us => 'Summer');
629:
630: e.g., @{$$cat_order{'Semester'}} = ('ss','us','fs');
631: returns 1 parameter: 'ok' if no processing errors.
1.33 bisitz 632:
633: Detailed help:
634: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp
635:
1.32 jms 636: =cut
637:
1.10 raeburn 638:
639: sub instcode_format () {
640: my ($dom,$instcodes,$codes,$codetitles,$cat_titles,$cat_order) = @_;
641: my $outcome = 'ok';
642: return $outcome;
643: }
644:
1.35 raeburn 645: =pod
646:
647: =item possible_instcodes()
648:
649: Gather acceptable values for institutional categories to use in course creation request form for official courses.
650:
1.40 raeburn 651: requires five arguments:
652:
1.35 raeburn 653: domain ($dom)
654: reference to array of titles ($codetitles)
655: reference to hash of abbreviations used in categories ($cat_titles).
1.40 raeburn 656: reference to hash of arrays specifying sort order used in
657: category titles ($cat_order).
658: reference to array which will contain order of component parts used
659: in institutional code ($code_order).
1.35 raeburn 660:
661: e.g.,
1.40 raeburn 662: @{$codetitles} = ('Year','Semester',"Department','Number');
1.35 raeburn 663:
664: %{$$cat_titles{'Semester'}} = (
665: fs => 'Fall',
666: ss => 'Spring',
667: us => 'Summer');
668:
669: @{$$cat_order{'Semester'}} = ('ss','us','fs');
1.40 raeburn 670: @{$code_order} = ('Semester','Year','Department','Number');
1.35 raeburn 671:
672: returns 1 parameter: 'ok' if no processing errors.
673:
674: =cut
675:
676: sub possible_instcodes {
1.40 raeburn 677: my ($dom,$codetitles,$cat_titles,$cat_order,$code_order) = @_;
1.35 raeburn 678: @{$codetitles} = ();
679: %{$$cat_titles{'Semester'}} = ();
680: @{$$cat_order{'Semester'}} = ('ss','us','fs');
1.40 raeburn 681: @{$code_order} = ();
1.35 raeburn 682: return 'ok';
683: }
684:
685:
1.32 jms 686: =pod
687:
688: =item institutional_photos()
689:
690: Called when automated enrollment manager is used to update student photos.
691:
692: Incoming data: six arguments
693: (a) $dom (domain)
694: (b) $crs (LONCAPA course number)
695: (c) $affiliates: a reference to a hash with the keys set to the
696: institutional course IDs for the course.
697: (d) $result: a reference to a hash which will return usernames
698: of students (& separated) in following categories (the keys):
699: new, update, missing, same, deleted, noid, nouser. The list
700: includes those students for whom the result of the modification
701: process was either addition of a new photo. update of an
702: existing photo, photo was found to be missing from institution's
703: data store, photo used is same as before, or photo was
704: deleted from storage on LON-CAPA server housing student's
1.34 weissno 705: information, no student/employee ID was available.
1.12 raeburn 706:
1.32 jms 707: (e) $action: the type of action needed. (e.g., update, delete);
708: (f) $students: a reference to a hash with the keys set to student
709: usernames and domains in the form username:domain, and values set
710: to the studentID, if action is required for specific students.
711:
712: returns 1 parameter: 'ok' if no processing errors.
713: other course or student specific values can be stored as values
714: in the appropriate referenced hashes.
715:
716: =cut
1.12 raeburn 717:
718: sub institutional_photos {
719: my ($dom,$crs,$affiliates,$result,$action,$students) = @_;
720: my $outcome = 'ok';
721: return $outcome;
722: }
723:
1.32 jms 724: =pod
725:
726: =item photo_permission()
727:
728: Incoming data: three arguments
729: (a) $dom (domain)
730: (b) $perm_reqd: a reference to a a scalar that is either 'yes'
731: if a course owner must indicate acceptance of conditions of use,
732: 'no' otherwise.
733: (c) $conditions: the text of the conditions of use.
734:
735: returns 1 parameter: 'ok' if no processing errors.
736: $$perm_reqd is set to 'yes' or 'no'
737: $$agreement is set to conditions of use - plain text string
738: which will be displayed in a textarea in a web form.
739:
740:
741: =cut
742:
1.12 raeburn 743: sub photo_permission {
744: my ($dom,$perm_reqd,$conditions) = @_;
745: $$perm_reqd = 'no';
746: $$conditions = '';
747: my $outcome = 'ok';
748: return $outcome;
749: }
750:
1.32 jms 751: =pod
752:
753: =item manager_photo_update()
754:
755: Incoming data: one argument
756: (a) $dom (domain)
757:
758: returns 2 parameters: update (0 or 1), and comment.
759: Called by automated enrollment manager, to determine
760: whether "Update Student photos" button will be available,
761: and if so, the message (plain text string) that will be displayed
762: with the button.
1.12 raeburn 763:
1.32 jms 764:
765: =cut
1.12 raeburn 766:
767: sub manager_photo_update {
768: my ($dom) = @_;
769: my $update = 0;
770: my $comment = '';
771: return ($update,$comment);
772: }
773:
1.32 jms 774: =pod
775:
776:
777: =item check_section()
778:
779: Incoming data: three arguments (+ fourth optional argument)
780: (a) $class - institutional class id (coursecode concatanated with section)
781: (b) $owner - course owner (2.2 and later username:domain; pre-2.2 username;
782: 2.6 and later - comma-separated list of
783: username:domain for course owner and co-owners.)
784: (c) $dom - domain of course
785: (d) $dbh - optional database handle
786:
787: returns 1 parameter - $sectioncheck ('ok' or other value).
788: Verifies that at least one of the course owner (or co-owners) have access
789: to classlist for specific class according to institution's SIS
790: 'ok' if access available
791:
792:
793: =cut
1.16 raeburn 794:
795: sub check_section {
796: my ($class,$owner,$dom,$dbh) = @_;
797: my $sectioncheck = 'ok';
798: return $sectioncheck;
799: }
800:
1.32 jms 801: =pod
802:
803: =item instcode_defaults()
804:
805: Incoming data: three arguments
806: (a) $dom - domain
807: (b) $defaults - reference to hash which will contain default regular
808: expression matches for different components of an
809: institutional course code
810: (c) $code_order - reference to array which will contain order of
811: component parts used in institutional code.
812:
813: returns 1 parameter - ('ok' or other value).
814: Used to construct a regular expression to be used when searching for
815: courses based on fragments of an institutional code.
816: $defaults contains defaults to use for each component, and code_order
817: contains keys of hash in order in which they are to be concatenated.
818:
819: e.g., INSTITUTIONALCODE = fs03nop590
820: (MSU's course naming scheme - fs = semester, 03 = year, nop =
821: department name, 590 = course number)
822:
823: %{$defaults} = (
824: 'Year' => '\d{2}',
825: 'Semester' => '^[sfu]s',
826: 'Department' => '\w{2,3}',
827: 'Number' => '\d{3,4}\w?',
828: );
829:
830: @{$code_order} = ('Semester','Year','Department','Number');
831:
1.33 bisitz 832: Detailed help:
833: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp
834:
1.32 jms 835: =cut
1.17 raeburn 836:
837: sub instcode_defaults {
838: my ($dom,$defaults,$code_order) = @_;
839: return 'ok';
840: }
841:
1.32 jms 842:
843: =pod
844:
845: =item allusers_info()
846:
847: Incoming data: three arguments
848: (a) $dom - domain
849: (b) $instusers - reference to hash which will contain hashes,
850: where keys will be usernames and value will be a
851: hash of user information. Keys in the inner hash
852: will be some or all of: lastname,firstname,
853: middlename, generation, id, inststatus -
854: institutional status (e.g., faculty,staff,student)
855: Values are all scalars except inststatus,
856: which is an array.
857: (c) $instids - reference to hash which will contain ID numbers.
858: keys will be unique IDs (student or faculty/staff ID)
859: values will be either: scalar (username) or an array
860: if a single ID matches multiple usernames.
1.43 raeburn 861: (d) $lc_users - reference to hash containing LON-CAPA usernames in
862: in domain $dom, as keys. Needed if institutional
863: data source only allows query by username.
1.32 jms 864: returns 1 parameter - 'ok' if no processing error, or other value
865: if an error occurred.
866: side effects - populates the $instusers and $instids refs to hashes.
867: with information for all users from all available
868: institutional datafeeds.
869:
870:
871: =cut
1.18 raeburn 872:
873: sub allusers_info {
1.43 raeburn 874: my ($dom,$instusers,$instids,$lc_users) = @_;
1.18 raeburn 875: my $outcome = 'ok';
876: return $outcome;
877: }
878:
1.32 jms 879: =pod
880:
881: =item get_userinfo()
882:
883: Incoming data: four required arguments and additional optional arguments
884: Two modes of operation:
885: (1) Retrieves institutional data for a single user either by username
886: if $uname is included as second argument, or by ID if $id is
887: included as a third argument. Either (b) or (c) must be provided.
888: (g), (h) and (i) will be undefined.
889: (2) Retrieves institutional user data from search of an institutional
890: directory based on a search. (g) and (h) are required.
891: (i) is optional. (b) and (c) will be undefined.
892:
893: (a) $dom - domain
894: (b) $uname - username of user
895: (c) $id - student/faculty ID of user
896: (d) $instusers - reference to hash which will contain info for user
897: as key = value; keys will be one or all of:
898: lastname,firstname,middlename,generation,id,inststatus -
899: institutional status (e.g., faculty,staff,student)
900: Values are all scalars except inststatus,
901: which is an array.
902: (e) $instids - reference to hash which will contain ID numbers -
903: keys will be unique IDs (student or faculty/staff ID)
904: values will be either: scalar (username) or an array
905: if a single ID matches multiple usernames.
906: (f) $types - optional reference to array which contains
907: institutional types to check.
908: (g) $srchby - optional if $uname or $id defined, otherwise required.
909: Allowed values include: 1. lastfirst, 2. last, 3. uname
910: corresponding to searches by 1. lastname,firstname;
911: 2. lastname; 3. username
912: (h) $srchterm - optional if $uname or $id defined, otherwise required
913: String to search for.
914: (i) $srchtype - optional. Allowed values: contains, begins (defaults
915: to exact match otherwise).
916:
917: returns 1 parameter - 'ok' if no processing error, or other value
918: if an error occurred.
919: side effects - populates the $instusers and $instids refs to hashes.
920: with information for specified username, or specified
921: id, if fifth argument provided, from all available, or
922: specified (e.g., faculty only) institutional datafeeds,
923: if sixth argument provided.
924:
925: WARNING: You need to set $outcome to 'ok' once you have customized
926: this routine to communicate with an instititional
927: directory data source, otherwise institutional directory
928: searches will always be reported as being unavailable
929: in domain $dom.
930:
931: =cut
1.18 raeburn 932:
933: sub get_userinfo {
1.21 raeburn 934: my ($dom,$uname,$id,$instusers,$instids,$types,
935: $srchby,$srchterm,$srchtype) = @_;
1.24 raeburn 936: my $outcome = 'unavailable';
1.18 raeburn 937: return $outcome;
938: }
939:
1.32 jms 940: =pod
941:
1.53 raeburn 942: =item get_multusersinfo
943:
944: (a) $dom - domain
945: (b) $type - username or id
946: (c) $unamenames - reference to hash containing usernames of users
947: (d) $instusers - reference to hash which will contain info for user
948: as key = value; keys will be one or all of:
949: lastname,firstname,middlename,generation,id,inststatus -
950: institutional status (e.g., faculty,staff,student)
951: Values are all scalars except inststatus,
952: which is an array.
953: (e) $instids - reference to hash which will contain ID numbers -
954: keys will be unique IDs (student or faculty/staff ID)
955: values will be either: scalar (username) or an array
956: if a single ID matches multiple usernames.
957:
958: returns 1 parameter - 'ok' if no processing error, or other value
959: if an error occurred.
960:
961: side effects - populates the $instusers and $instids refs to hashes.
962: with information for specified username, or specified
963: id, if fifth argument provided, from all available, or
964: specified (e.g., faculty only) institutional datafeeds,
965: if sixth argument provided.
966:
967: WARNING: You need to set $outcome to 'ok' once you have customized
968: this routine to communicate with an instititional
969: directory data source, otherwise retrieval of institutional
970: user information will always be reported as being unavailable
971: in domain $dom.
972:
973: =cut
974:
975: sub get_multusersinfo {
976: my ($dom,$type,$usernames,$instusers,$instids) = @_;
977: my $outcome = 'unavailable';
978: return $outcome;
979: }
980:
981: =pod
982:
1.32 jms 983: =item inst_usertypes()
984:
1.49 raeburn 985: Starting with LON-CAPA 2.11.0 use of this subroutine
986: is deprecated. The domain configuration web GUI
987: accessible to Domain Coordinators will be used to
988: manage institutional types. If you have previously
989: customized this routine, then values set there will
990: be used when displaying the "Institutional user types"
991: section in the domain config screen for:
992: "Default authentication/language/timezone/portal/types".
993:
994: Once you have visited that screen and saved the settings,
995: configuration thereafter will be via the web GUI of
996: values stored in the domain's configuration.db file on
997: the primary library server in the domain, and values in
998: inst_usertypes() will no longer be consulted.
999:
1.32 jms 1000: Incoming data: three arguments
1001: (a) $dom - domain
1002: (b) $usertypes - reference to hash which will contain
1003: key = value, where keys are institution
1004: affiliation types (e.g., Faculty, Student etc.)
1005: and values are titles (e.g., Faculty/Academic Staff)
1006: (c) $order - reference to array which will contain the order in
1007: which institutional types should be shown
1008: when displaying data tables (e.g., default quotas
1009: or updateable user fields (see domainprefs.pm)
1010: returns 1 parameter - 'ok' if no processing error, or other value
1011: if an error occurred.
1012:
1013:
1014: =cut
1.18 raeburn 1015:
1016: sub inst_usertypes {
1017: my ($dom,$usertypes,$order) = @_;
1.20 raeburn 1018: @{$order} = ();
1019: %{$usertypes} = ();
1.18 raeburn 1020: my $outcome = 'ok';
1021: return $outcome;
1022: }
1.17 raeburn 1023:
1.32 jms 1024: =pod
1025:
1026: =item username_rules()
1027:
1028: Incoming data: three arguments
1029: (a) $dom - domain
1030: (b) $ruleshash - reference to hash containing rules
1031: (a hash of a hash)
1032: keys of top level hash are short names
1033: (e.g., netid, noncredit)
1034: for each key, value is a hash
1035: desc => long name for rule
1036: rule => description of rule
1037: authtype => (krb5,krb4,int, or loc)
1038: authentication type for rule
1039: authparm => authentication parameter for rule
1040: authparmfixed => 1 if authparm used when
1041: creating user for rule must be authparm
1042: authmsg => Message to display describing
1043: authentication to use for this rule
1044:
1045: (c) $rulesorder - reference to array containing rule names
1046: in order to be displayed
1047:
1048:
1049: returns 'ok' if no processing error.
1.25 raeburn 1050:
1.32 jms 1051: =cut
1.25 raeburn 1052:
1053: sub username_rules {
1054: my ($dom,$ruleshash,$rulesorder) = @_;
1055: my $outcome;
1056: return $outcome;
1057: }
1058:
1.32 jms 1059: =pod
1060:
1061: =item id_rules()
1062:
1063: Incoming data: three arguments
1064: (a) $dom - domain
1065: (b) $ruleshash - reference to hash containing rules
1066: (a hash of a hash)
1067: keys of top level hash are short names
1068: (e.g., netid, noncredit)
1069: for each key, value is a hash
1070: desc => long name for rule
1071: rule => description of rule
1072:
1073: (c) $rulesorder - reference to array containing rule names
1074: in order to be displayed
1075:
1076: returns 'ok' if no processing error.
1077:
1078: =cut
1.27 raeburn 1079:
1.30 raeburn 1080: sub id_rules {
1081: my ($dom,$ruleshash,$rulesorder) = @_;
1082: my $outcome;
1083: return $outcome;
1084: }
1085:
1.32 jms 1086: =pod
1087:
1088: =item selfcreate_rules()
1089:
1090: Incoming data: three arguments
1091: (a) $dom - domain
1092: (b) $ruleshash - reference to hash containing rules
1093: (a hash of a hash)
1094: keys of top level hash are short names
1095: (e.g., netid)
1096: for each key, value is a hash
1097: desc => long name for rule
1098: rule => description of rule
1099:
1100: (c) $rulesorder - reference to array containing rule names
1101: in order to be displayed
1102:
1103: returns 'ok' if no processing error.
1104:
1.27 raeburn 1105:
1.32 jms 1106: =cut
1.30 raeburn 1107:
1.31 raeburn 1108: sub selfcreate_rules {
1.27 raeburn 1109: my ($dom,$ruleshash,$rulesorder) = @_;
1110: my $outcome;
1111: return $outcome;
1112: }
1113:
1.32 jms 1114: =pod
1115:
1116: =item username_check()
1117:
1118: Incoming data: four arguments
1119: (a) $dom - domain (scalar)
1120: (b) $uname - username to compare against rules (scalar)
1121: (c) $to_check (reference to array of rule names to check)
1122: (d) $resultshash (reference to hash of results)
1123: hash of results for rule checked
1124: - keys are rule names
1125: - values are: 1 or 0 (for matched or unmatched)
1126:
1127: returns 'ok' if no processing error.
1128:
1129:
1130: =cut
1.25 raeburn 1131:
1132: sub username_check {
1133: my ($dom,$uname,$to_check,$resultshash) = @_;
1134: my $outcome;
1135: return $outcome;
1136: }
1137:
1.32 jms 1138: =pod
1139:
1140: =item id_check()
1141:
1142: Incoming data: four arguments
1143: (a) $dom - domain (scalar)
1144: (b) $id - ID to compare against rules (scalar)
1145: (c) $to_check (reference to array of rule names to check)
1146: (d) $resultshash (reference to hash of results)
1147: hash of results for rule checked
1148: - keys are rule names
1149: - values are: 1 or 0 (for matched or unmatched)
1150:
1151: returns 'ok' if no processing error.
1152:
1153:
1154: =cut
1.27 raeburn 1155:
1156: sub id_check {
1157: my ($dom,$id,$to_check,$resultshash) = @_;
1158: my $outcome;
1159: return $outcome;
1160: }
1161:
1.32 jms 1162: =pod
1163:
1164: =item selfcreate_check()
1165:
1166: Incoming data: four arguments
1167: (a) $dom - domain (scalar)
1168: (b) $selfcreatename - e-mail proposed as username (compare against rules - scalar)
1169: (c) $to_check (reference to array of rule names to check)
1170: (d) $resultshash (reference to hash of results)
1171: hash of results for rule checked
1172: - keys are rule names
1173: - values are: 1 or 0 (for matched or unmatched)
1174:
1175: returns 'ok' if no processing error.
1176:
1177:
1178: =cut
1.30 raeburn 1179:
1.31 raeburn 1180: sub selfcreate_check {
1181: my ($dom,$selfcreatename,$to_check,$resultshash) = @_;
1.30 raeburn 1182: my $outcome;
1183: return $outcome;
1184: }
1185:
1.32 jms 1186: =pod
1187:
1188: =item AUTOLOAD()
1189:
1190: Incoming data: none
1191: Returns ''
1192:
1193: Prevents errors when undefined subroutines are called in this package
1194: Will allow new routines added in the future to be called from lond etc.
1195: without the need for customized versions of local*.pm packages to be
1196: modified to include the new subroutines immediately.
1197:
1198: See "Programming Perl" 3rd ed. pp 296-298.
1199:
1200: =back
1201:
1202: =cut
1.14 raeburn 1203:
1204: sub AUTOLOAD {
1205: our $AUTOLOAD;
1206: return '';
1207: }
1208:
1.1 raeburn 1209: 1;
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to localenroll.pm CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [LON-CAPA] / loncom / enrollment