loncom/enrollment/localenroll.pm - view

File: [LON-CAPA] / loncom / enrollment / localenroll.pm
Revision 1.53: download - view: text, annotated - select for diffs
Wed Aug 5 18:47:17 2015 UTC (8 years, 11 months ago) by raeburn
Branches: MAIN
CVS tags: HEAD

- Bug 5596.
  Add a routine to lonnet.pm -- get_multiple_instusers() which makes one call
  to lond > lonsql > localenroll.pm to retrieve institutional data
  for multiple users when adding users via file upload, to minimize number
  of sleep() commands needed. Supports up to 1s per query, on localenroll.pm
  side if adding more than 100 new users.

- Add new routine to localenroll.pm -- &get_multusersinfo() -- to retrieve
    institutional data for users being added via user file upload.

  Note: if this routine does not exist in localenroll.pm, will fall-back
  to retrieving institutional data using a separate call to &get_userinfo()
  for each user.

1: # functions to glue school database system into Lon-CAPA for 2: # automated enrollment 3: # $Id: localenroll.pm,v 1.53 2015/08/05 18:47:17 raeburn Exp $ 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: # 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: 46: package localenroll; 47: 48: use strict; 49: 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 61: 62: sub run() { 63: my $dom = shift; 64: return 0; 65: } 66: 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> 126: <credits></credits> 127: <inststatus></inststatus> 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: 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 155: modify a course or community" on the DC's Main Menu screen. 156: 157: A value for <inststatus> should be the institutional status used for students, 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. 165: 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 189: 190: sub fetch_enrollment { 191: my ($dom,$affiliatesref,$replyref) = @_; 192: foreach my $crs (sort keys %{$affiliatesref}) { 193: $$replyref{$crs} = 0; 194: } 195: my $okflag = 0; 196: return $okflag; 197: } 198: 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 226: 227: sub get_sections { 228: my ($coursecode,$dom) = @_; 229: my @secs = (); 230: return @secs; 231: } 232: 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: 252: new_course takes three required arguments - 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: 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: 265: =cut 266: 267: sub new_course { 268: my ($course_id,$owner,$dom,$coowners) = @_; 269: my $outcome = 'ok'; 270: return $outcome; 271: } 272: 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 293: 294: sub validate_courseID { 295: my ($course_id,$dom) = @_; 296: my $outcome = 'ok'; 297: return $outcome; 298: } 299: 300: =pod 301: 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: 313: validate_instcode takes three arguments - 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: 319: An array is returned containing (a) the result of the check for a valid 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: 326: A valid instcode is confirmed by returning 'valid'. 327: 328: If no course description is available, '' should be set as 329: the value of the second item in the returned array. 330: 331: =cut 332: 333: sub validate_instcode { 334: my ($dom,$instcode,$owner) = @_; 335: my $outcome = ''; 336: my $description = ''; 337: my $credits = ''; 338: return ($outcome,$description,$credits); 339: } 340: 341: =pod 342: 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 350: to 'validate' for the course type (official, unofficial or community) and 351: the requestor's affiliation. Whether "validate" is an available option 352: in the Domain Configuration menu is controlled by auto_courserequest_checks(). 353: One scenario is where the request is for an official course, in which case 354: a check could be made that the requestor is listed as instructor of 355: record for the course in the institution's course schedule/database. 356: 357: Other scenarios are possible, and the routine can be customized according 358: to whatever rules a domain wishes to implement to run validations against 359: given the data passed in to the routine. 360: 361: validate_crsreq takes seven arguments - 362: (a) the LON-CAPA domain that will contain the course. 363: (b) the username:domain for the course owner. 364: (c) the course type (official, unofficial or community) 365: (d) a comma-separated list of institutional affiliations of 366: the course owner. 367: (e) the institutional code (in the MSU case this is a concatenation of 368: semester code, department code, and course number, e.g., fs03nop590). 369: (f) a comma-separated list of institutional sections included in 370: the course request (only applicable to official courses). 371: (g) an optional reference to a hash of custom form data. 372: The custom form data will come from crsreq_updates(), with one 373: additional item: $custominfo->{'_LC_clonefrom'}, provided internally 374: (the courseID of the LON-CAPA course being cloned). 375: 376: A valid courserequest is confirmed by returning 'process'. 377: The following can be returned: process, rejected, pending, approval or 378: error (with error condition - no :), followed by a : and then an optional message. 379: 380: (a) process - the requestor is the recorded instructor - create the course 381: 382: (b) rejected - the requestor should never be requesting this course, reject the 383: request permanently 384: 385: (c) pending - the requestor is not the recorded instructor, but could 386: become so after administrative action at the institution. Put the 387: request in a queue and, if an official course, check 388: localenroll:validate_instcode() periodically until the status changes to 389: "valid". 390: 391: (d) approval - the request will be held pending review by a Domain Coordinator. 392: 393: (e) error (followed by the error condition). 394: 395: =cut 396: 397: sub validate_crsreq { 398: my ($dom,$owner,$crstype,$inststatuslist,$instcode,$instseclist,$custominfo) = @_; 399: my $outcome = 'approval'; 400: return $outcome; 401: } 402: 403: =pod 404: 405: =item crsreq_checks() 406: 407: This is used to determine whether the "validate" option should appear in the 408: possible choices for course request processing in the Domain Configuration 409: menu for Course Requests. Ultimately it is called by domainprefs.pm (via: 410: lonnet -> lond -> localenroll.pm) The domain configuration menu includes 411: a table where columns are course type (official, unofficial or community) 412: and rows are institutional affiliations (e.g., Faculty, Staff, Student etc.). 413: 414: crsreq_checks() takes three arguments: $dom, $reqtypes, $validations. 415: $dom - the domain for which validation options are needed. 416: $reqtypes - ref to an ARRAY of course types (i.e., official, unofficial and community. 417: $validations - ref to a hash of a hash which will determine whether "validate" 418: will be one of the possible choices for each course type (outer hash key), 419: and institutional type (inner hash key). 420: 421: For example to allow validate to be a choice for official classes for Faculty, 422: req_checks would include: 423: 424: $validations{'official'}{'Faculty'} = 1; 425: 426: This routine is closely tied to validate_crsreq(). "Validate" should not be 427: a possible choice in the domain configuration menu for a particular course 428: type/institutional affiliation, unless a corresponding validation code has 429: been implemented in validate_crsreq(). 430: 431: For example at MSU, official courses requested by Faculty will be validated 432: against the official schedule of classes to check that the requestor is one 433: of the instructors of record for the course. In this case validate_crsreq() 434: includes a call to validate_instcode(). 435: 436: =cut 437: 438: sub crsreq_checks { 439: my ($dom,$reqtypes,$validations) = @_; 440: if ((ref($reqtypes) eq 'ARRAY') && (ref($validations) eq 'HASH')) { 441: my (%usertypes,@order); 442: if (&inst_usertypes($dom,\%usertypes,\@order) eq 'ok') { 443: foreach my $type (@{$reqtypes}) { 444: foreach my $inst_type (@order) { 445: $validations->{$type}{$inst_type} = 0; 446: } 447: } 448: } 449: } 450: return 'ok'; 451: } 452: 453: =pod 454: 455: =item crsreq_updates() 456: 457: This is used to customize the LON-CAPA course request process. 458: There are two hash references: $incoming, and $outgoing; $incoming can 459: contain additional information collected from the requester, whereas $outgoing 460: can contain custom items to send back to lonrequestcourse.pm, which creates the 461: HTML displayed to the user during a course request. 462: 463: Different key-value pairs may be returned to lonrequestcourse.pm in the $outgoing 464: hashref depending on the current action. The available actions are: 465: review, prevalidate, process, created and queued. 466: 467: One scenario would be to return HTML markup in: $outgoing->{'reviewweb'}, 468: i.e., where the action is 'review', to prompt the user to provide additional 469: information as part of the course request, at the request review stage, 470: (i.e,, the page which contains the button used to submit a completed course request). 471: 472: The HTML could contain form elements (e.g., radio buttons etc.). The value(s) 473: selected by the requester in those form elements will be available in the incoming 474: hashref, for a subsequent action, if the corresponding keys have been included 475: in $outgoing->{'formitems'}, i.e., $outgoing will be hash of a hash. If a 476: particular form item will the single valued, the value set for the key in the 477: inner hash in $outgoing should be 1, otherwise, if it will be multi-valued, 478: the value should be multiple. 479: 480: The $outgoing hashref can contain a 'formitems' key for both the prevalidate 481: and process actions, as calls to localenroll::crsreq_update() can originate 482: in lonrequestcourse::process_request() for both of those actions. 483: 484: The retrieved form values are passed to localenroll::validate_crsreq() as the 485: optional seventh arg (a hashref) -- $custominfo. 486: 487: =cut 488: 489: sub crsreq_updates { 490: my ($cdom,$cnum,$crstype,$action,$ownername,$ownerdomain,$fullname,$title, 491: $code,$accessstart,$accessend,$incoming,$outgoing) = @_; 492: unless (ref($outgoing) eq 'HASH') { 493: return 'fail'; 494: } 495: my %extrainfo; 496: if (ref($incoming) eq 'HASH') { 497: %extrainfo = %{$incoming}; 498: } 499: if ($action eq 'review') { 500: $outgoing->{'reviewweb'} = ''; 501: } elsif ($action eq 'prevalidate') { 502: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name 503: # and value is multiple, if there 504: # are multiple form elements with 505: # the same name. 506: } elsif ($action eq 'process') { 507: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name 508: # and value is multiple, if there 509: # are multiple form elements with 510: # the same name. 511: } elsif ($action eq 'created') { 512: $outgoing->{'createdweb'} = ''; 513: $outgoing->{'createdmsg'} = [{ 514: mt => '', 515: args => [], 516: }]; 517: $outgoing->{'createdactions'} = { 518: environment => {}, 519: }; 520: # environment can contain key=>value for 521: # items to set in the course environment. 522: # These would be items which are NOT included 523: # in the items set via options in the course 524: # request form. Currently self-enrollment 525: # settings are the only ones allowed, i.e., 526: # internal.selfenroll_types internal.selfenroll_registered 527: # internal.selfenroll_section internal.selfenroll_start_access 528: # internal.selfenroll_end_access internal.selfenroll_limit 529: # internal.selfenroll_cap internal.selfenroll_approval 530: # internal.selfenroll_notifylist 531: } elsif ($action eq 'queued') { 532: $outgoing->{'queuedmsg'} = [{ 533: mt => '', 534: args => [], 535: }]; 536: $outgoing->{'queuedweb'} = ''; 537: } 538: return 'ok' 539: } 540: 541: =pod 542: 543: =item create_password() 544: 545: This is called when the authentication method set for the automated 546: enrollment process when enrolling new users in the domain is "localauth". 547: This could be signalled for the specific user by the value of localauth 548: for the <authtype> tag from the classlist.xml files, or if this is blank, 549: the default authtype, set by the domain coordinator when creating the course 550: with loncreatecourse.pm. 551: 552: create_password takes three arguments - 553: (a) $authparam - the value of <autharg> from the classlist.xml files, 554: or if this blank, the default autharg, set by the domain coordinator when 555: creating the course with loncreatecourse.pm 556: (b) $dom - the domain of the new user. 557: (c) $username - the username of the new user (currently not actually used) 558: 559: Four values are returned: 560: (a) the value of $authparam - which might have been changed 561: (b) a flag to indicate whether a password had been created 562: 0 means no password created 563: 1 means password created. In this case the calling module - Enrollment.pm 564: will send the LON-CAPA username and password to the new user's e-mail 565: (if one was provided), or to the course owner (if one was not provided and 566: the new user was created by the automated process), or to the active 567: course coordinator (if the new user was created using the 'update roster 568: now' interface included in the Automated Enrollment Manager). 569: (c) a flag to indicate that the authentication method is correct - 'ok'. 570: If $authchk is not set to 'ok' then account creation and enrollment of the 571: new user will not occur. 572: (d) if a password was created it can be sent along. This is the password 573: which will be included in the e-mail sent to the new user, or made available 574: to the course owner/course coordinator if no e-mail address is provided. If 575: you do not wish to send a password, but want to give instructions on obtaining 576: one, you could set $newpasswd as those instructions. (e.g., 577: $newpasswd = '(Please visit room 212, ACNS Bldg. to obtain your password)'; 578: The value of $newpasswd is NOT written in the user's LON-CAPA passwd file in 579: /home/httpd/lonUsers/$dom/a/b/c/abcuser/passwd, which in the case of a user 580: employing localauth will contain 'localauth:$authparam'. If you need to include 581: a parameter in the user's passwd file, you should return it as $authparam, 582: i.e., the first of the variables returned by create_password(). 583: 584: 585: =cut 586: 587: sub create_password { 588: my ($authparam,$dom,$username) = @_; 589: my $authchk = 'ok'; 590: my $newpasswd = ''; 591: my $create_passwd = 0; 592: return ($authparam,$create_passwd,$authchk,$newpasswd); 593: } 594: 595: =pod 596: 597: =item instcode_format() 598: 599: Split coursecodes into constituent parts. 600: e.g., INSTITUTIONALCODE = fs03nop590, LON-CAPA COURSEID: 43551dedcd43febmsul1 601: (MSU's course naming scheme - fs03 = Fall semester 2003, nop = 602: department name, 590 = course number) 603: 604: Incoming data: 605: $dom (domain) 606: $$instcodes{'43551dedcd43febmsul1'} = 'fs03nop590' (hash of courseIDs) 607: 608: fs03nop590 would be split as follows 609: @{$codetitles} = ("year","semester","department","number") 610: $$codes{'year'} = '2003' 611: $$codes{'semester'} = 'Fall' 612: $$codes{'department'} = 'nop' 613: $$codes{'number'} = '590' 614: 615: requires six arguments: 616: domain ($dom) 617: reference to hash of institutional course IDs ($instcodes) 618: reference to hash of codes ($codes) 619: reference to array of titles ($codetitles) 620: reference to hash of abbreviations used in categories 621: reference to hash of arrays specifying sort order used in category titles 622: 623: e.g., %{$$cat_titles{'Semester'}} = ( 624: fs => 'Fall', 625: ss => 'Spring', 626: us => 'Summer'); 627: 628: e.g., @{$$cat_order{'Semester'}} = ('ss','us','fs'); 629: returns 1 parameter: 'ok' if no processing errors. 630: 631: Detailed help: 632: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp 633: 634: =cut 635: 636: 637: sub instcode_format () { 638: my ($dom,$instcodes,$codes,$codetitles,$cat_titles,$cat_order) = @_; 639: my $outcome = 'ok'; 640: return $outcome; 641: } 642: 643: =pod 644: 645: =item possible_instcodes() 646: 647: Gather acceptable values for institutional categories to use in course creation request form for official courses. 648: 649: requires five arguments: 650: 651: domain ($dom) 652: reference to array of titles ($codetitles) 653: reference to hash of abbreviations used in categories ($cat_titles). 654: reference to hash of arrays specifying sort order used in 655: category titles ($cat_order). 656: reference to array which will contain order of component parts used 657: in institutional code ($code_order). 658: 659: e.g., 660: @{$codetitles} = ('Year','Semester',"Department','Number'); 661: 662: %{$$cat_titles{'Semester'}} = ( 663: fs => 'Fall', 664: ss => 'Spring', 665: us => 'Summer'); 666: 667: @{$$cat_order{'Semester'}} = ('ss','us','fs'); 668: @{$code_order} = ('Semester','Year','Department','Number'); 669: 670: returns 1 parameter: 'ok' if no processing errors. 671: 672: =cut 673: 674: sub possible_instcodes { 675: my ($dom,$codetitles,$cat_titles,$cat_order,$code_order) = @_; 676: @{$codetitles} = (); 677: %{$$cat_titles{'Semester'}} = (); 678: @{$$cat_order{'Semester'}} = ('ss','us','fs'); 679: @{$code_order} = (); 680: return 'ok'; 681: } 682: 683: 684: =pod 685: 686: =item institutional_photos() 687: 688: Called when automated enrollment manager is used to update student photos. 689: 690: Incoming data: six arguments 691: (a) $dom (domain) 692: (b) $crs (LONCAPA course number) 693: (c) $affiliates: a reference to a hash with the keys set to the 694: institutional course IDs for the course. 695: (d) $result: a reference to a hash which will return usernames 696: of students (& separated) in following categories (the keys): 697: new, update, missing, same, deleted, noid, nouser. The list 698: includes those students for whom the result of the modification 699: process was either addition of a new photo. update of an 700: existing photo, photo was found to be missing from institution's 701: data store, photo used is same as before, or photo was 702: deleted from storage on LON-CAPA server housing student's 703: information, no student/employee ID was available. 704: 705: (e) $action: the type of action needed. (e.g., update, delete); 706: (f) $students: a reference to a hash with the keys set to student 707: usernames and domains in the form username:domain, and values set 708: to the studentID, if action is required for specific students. 709: 710: returns 1 parameter: 'ok' if no processing errors. 711: other course or student specific values can be stored as values 712: in the appropriate referenced hashes. 713: 714: =cut 715: 716: sub institutional_photos { 717: my ($dom,$crs,$affiliates,$result,$action,$students) = @_; 718: my $outcome = 'ok'; 719: return $outcome; 720: } 721: 722: =pod 723: 724: =item photo_permission() 725: 726: Incoming data: three arguments 727: (a) $dom (domain) 728: (b) $perm_reqd: a reference to a a scalar that is either 'yes' 729: if a course owner must indicate acceptance of conditions of use, 730: 'no' otherwise. 731: (c) $conditions: the text of the conditions of use. 732: 733: returns 1 parameter: 'ok' if no processing errors. 734: $$perm_reqd is set to 'yes' or 'no' 735: $$agreement is set to conditions of use - plain text string 736: which will be displayed in a textarea in a web form. 737: 738: 739: =cut 740: 741: sub photo_permission { 742: my ($dom,$perm_reqd,$conditions) = @_; 743: $$perm_reqd = 'no'; 744: $$conditions = ''; 745: my $outcome = 'ok'; 746: return $outcome; 747: } 748: 749: =pod 750: 751: =item manager_photo_update() 752: 753: Incoming data: one argument 754: (a) $dom (domain) 755: 756: returns 2 parameters: update (0 or 1), and comment. 757: Called by automated enrollment manager, to determine 758: whether "Update Student photos" button will be available, 759: and if so, the message (plain text string) that will be displayed 760: with the button. 761: 762: 763: =cut 764: 765: sub manager_photo_update { 766: my ($dom) = @_; 767: my $update = 0; 768: my $comment = ''; 769: return ($update,$comment); 770: } 771: 772: =pod 773: 774: 775: =item check_section() 776: 777: Incoming data: three arguments (+ fourth optional argument) 778: (a) $class - institutional class id (coursecode concatanated with section) 779: (b) $owner - course owner (2.2 and later username:domain; pre-2.2 username; 780: 2.6 and later - comma-separated list of 781: username:domain for course owner and co-owners.) 782: (c) $dom - domain of course 783: (d) $dbh - optional database handle 784: 785: returns 1 parameter - $sectioncheck ('ok' or other value). 786: Verifies that at least one of the course owner (or co-owners) have access 787: to classlist for specific class according to institution's SIS 788: 'ok' if access available 789: 790: 791: =cut 792: 793: sub check_section { 794: my ($class,$owner,$dom,$dbh) = @_; 795: my $sectioncheck = 'ok'; 796: return $sectioncheck; 797: } 798: 799: =pod 800: 801: =item instcode_defaults() 802: 803: Incoming data: three arguments 804: (a) $dom - domain 805: (b) $defaults - reference to hash which will contain default regular 806: expression matches for different components of an 807: institutional course code 808: (c) $code_order - reference to array which will contain order of 809: component parts used in institutional code. 810: 811: returns 1 parameter - ('ok' or other value). 812: Used to construct a regular expression to be used when searching for 813: courses based on fragments of an institutional code. 814: $defaults contains defaults to use for each component, and code_order 815: contains keys of hash in order in which they are to be concatenated. 816: 817: e.g., INSTITUTIONALCODE = fs03nop590 818: (MSU's course naming scheme - fs = semester, 03 = year, nop = 819: department name, 590 = course number) 820: 821: %{$defaults} = ( 822: 'Year' => '\d{2}', 823: 'Semester' => '^[sfu]s', 824: 'Department' => '\w{2,3}', 825: 'Number' => '\d{3,4}\w?', 826: ); 827: 828: @{$code_order} = ('Semester','Year','Department','Number'); 829: 830: Detailed help: 831: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp 832: 833: =cut 834: 835: sub instcode_defaults { 836: my ($dom,$defaults,$code_order) = @_; 837: return 'ok'; 838: } 839: 840: 841: =pod 842: 843: =item allusers_info() 844: 845: Incoming data: three arguments 846: (a) $dom - domain 847: (b) $instusers - reference to hash which will contain hashes, 848: where keys will be usernames and value will be a 849: hash of user information. Keys in the inner hash 850: will be some or all of: lastname,firstname, 851: middlename, generation, id, inststatus - 852: institutional status (e.g., faculty,staff,student) 853: Values are all scalars except inststatus, 854: which is an array. 855: (c) $instids - reference to hash which will contain ID numbers. 856: keys will be unique IDs (student or faculty/staff ID) 857: values will be either: scalar (username) or an array 858: if a single ID matches multiple usernames. 859: (d) $lc_users - reference to hash containing LON-CAPA usernames in 860: in domain $dom, as keys. Needed if institutional 861: data source only allows query by username. 862: returns 1 parameter - 'ok' if no processing error, or other value 863: if an error occurred. 864: side effects - populates the $instusers and $instids refs to hashes. 865: with information for all users from all available 866: institutional datafeeds. 867: 868: 869: =cut 870: 871: sub allusers_info { 872: my ($dom,$instusers,$instids,$lc_users) = @_; 873: my $outcome = 'ok'; 874: return $outcome; 875: } 876: 877: =pod 878: 879: =item get_userinfo() 880: 881: Incoming data: four required arguments and additional optional arguments 882: Two modes of operation: 883: (1) Retrieves institutional data for a single user either by username 884: if $uname is included as second argument, or by ID if $id is 885: included as a third argument. Either (b) or (c) must be provided. 886: (g), (h) and (i) will be undefined. 887: (2) Retrieves institutional user data from search of an institutional 888: directory based on a search. (g) and (h) are required. 889: (i) is optional. (b) and (c) will be undefined. 890: 891: (a) $dom - domain 892: (b) $uname - username of user 893: (c) $id - student/faculty ID of user 894: (d) $instusers - reference to hash which will contain info for user 895: as key = value; keys will be one or all of: 896: lastname,firstname,middlename,generation,id,inststatus - 897: institutional status (e.g., faculty,staff,student) 898: Values are all scalars except inststatus, 899: which is an array. 900: (e) $instids - reference to hash which will contain ID numbers - 901: keys will be unique IDs (student or faculty/staff ID) 902: values will be either: scalar (username) or an array 903: if a single ID matches multiple usernames. 904: (f) $types - optional reference to array which contains 905: institutional types to check. 906: (g) $srchby - optional if $uname or $id defined, otherwise required. 907: Allowed values include: 1. lastfirst, 2. last, 3. uname 908: corresponding to searches by 1. lastname,firstname; 909: 2. lastname; 3. username 910: (h) $srchterm - optional if $uname or $id defined, otherwise required 911: String to search for. 912: (i) $srchtype - optional. Allowed values: contains, begins (defaults 913: to exact match otherwise). 914: 915: returns 1 parameter - 'ok' if no processing error, or other value 916: if an error occurred. 917: side effects - populates the $instusers and $instids refs to hashes. 918: with information for specified username, or specified 919: id, if fifth argument provided, from all available, or 920: specified (e.g., faculty only) institutional datafeeds, 921: if sixth argument provided. 922: 923: WARNING: You need to set $outcome to 'ok' once you have customized 924: this routine to communicate with an instititional 925: directory data source, otherwise institutional directory 926: searches will always be reported as being unavailable 927: in domain $dom. 928: 929: =cut 930: 931: sub get_userinfo { 932: my ($dom,$uname,$id,$instusers,$instids,$types, 933: $srchby,$srchterm,$srchtype) = @_; 934: my $outcome = 'unavailable'; 935: return $outcome; 936: } 937: 938: =pod 939: 940: =item get_multusersinfo 941: 942: (a) $dom - domain 943: (b) $type - username or id 944: (c) $unamenames - reference to hash containing usernames of users 945: (d) $instusers - reference to hash which will contain info for user 946: as key = value; keys will be one or all of: 947: lastname,firstname,middlename,generation,id,inststatus - 948: institutional status (e.g., faculty,staff,student) 949: Values are all scalars except inststatus, 950: which is an array. 951: (e) $instids - reference to hash which will contain ID numbers - 952: keys will be unique IDs (student or faculty/staff ID) 953: values will be either: scalar (username) or an array 954: if a single ID matches multiple usernames. 955: 956: returns 1 parameter - 'ok' if no processing error, or other value 957: if an error occurred. 958: 959: side effects - populates the $instusers and $instids refs to hashes. 960: with information for specified username, or specified 961: id, if fifth argument provided, from all available, or 962: specified (e.g., faculty only) institutional datafeeds, 963: if sixth argument provided. 964: 965: WARNING: You need to set $outcome to 'ok' once you have customized 966: this routine to communicate with an instititional 967: directory data source, otherwise retrieval of institutional 968: user information will always be reported as being unavailable 969: in domain $dom. 970: 971: =cut 972: 973: sub get_multusersinfo { 974: my ($dom,$type,$usernames,$instusers,$instids) = @_; 975: my $outcome = 'unavailable'; 976: return $outcome; 977: } 978: 979: =pod 980: 981: =item inst_usertypes() 982: 983: Starting with LON-CAPA 2.11.0 use of this subroutine 984: is deprecated. The domain configuration web GUI 985: accessible to Domain Coordinators will be used to 986: manage institutional types. If you have previously 987: customized this routine, then values set there will 988: be used when displaying the "Institutional user types" 989: section in the domain config screen for: 990: "Default authentication/language/timezone/portal/types". 991: 992: Once you have visited that screen and saved the settings, 993: configuration thereafter will be via the web GUI of 994: values stored in the domain's configuration.db file on 995: the primary library server in the domain, and values in 996: inst_usertypes() will no longer be consulted. 997: 998: Incoming data: three arguments 999: (a) $dom - domain 1000: (b) $usertypes - reference to hash which will contain 1001: key = value, where keys are institution 1002: affiliation types (e.g., Faculty, Student etc.) 1003: and values are titles (e.g., Faculty/Academic Staff) 1004: (c) $order - reference to array which will contain the order in 1005: which institutional types should be shown 1006: when displaying data tables (e.g., default quotas 1007: or updateable user fields (see domainprefs.pm) 1008: returns 1 parameter - 'ok' if no processing error, or other value 1009: if an error occurred. 1010: 1011: 1012: =cut 1013: 1014: sub inst_usertypes { 1015: my ($dom,$usertypes,$order) = @_; 1016: @{$order} = (); 1017: %{$usertypes} = (); 1018: my $outcome = 'ok'; 1019: return $outcome; 1020: } 1021: 1022: =pod 1023: 1024: =item username_rules() 1025: 1026: Incoming data: three arguments 1027: (a) $dom - domain 1028: (b) $ruleshash - reference to hash containing rules 1029: (a hash of a hash) 1030: keys of top level hash are short names 1031: (e.g., netid, noncredit) 1032: for each key, value is a hash 1033: desc => long name for rule 1034: rule => description of rule 1035: authtype => (krb5,krb4,int, or loc) 1036: authentication type for rule 1037: authparm => authentication parameter for rule 1038: authparmfixed => 1 if authparm used when 1039: creating user for rule must be authparm 1040: authmsg => Message to display describing 1041: authentication to use for this rule 1042: 1043: (c) $rulesorder - reference to array containing rule names 1044: in order to be displayed 1045: 1046: 1047: returns 'ok' if no processing error. 1048: 1049: =cut 1050: 1051: sub username_rules { 1052: my ($dom,$ruleshash,$rulesorder) = @_; 1053: my $outcome; 1054: return $outcome; 1055: } 1056: 1057: =pod 1058: 1059: =item id_rules() 1060: 1061: Incoming data: three arguments 1062: (a) $dom - domain 1063: (b) $ruleshash - reference to hash containing rules 1064: (a hash of a hash) 1065: keys of top level hash are short names 1066: (e.g., netid, noncredit) 1067: for each key, value is a hash 1068: desc => long name for rule 1069: rule => description of rule 1070: 1071: (c) $rulesorder - reference to array containing rule names 1072: in order to be displayed 1073: 1074: returns 'ok' if no processing error. 1075: 1076: =cut 1077: 1078: sub id_rules { 1079: my ($dom,$ruleshash,$rulesorder) = @_; 1080: my $outcome; 1081: return $outcome; 1082: } 1083: 1084: =pod 1085: 1086: =item selfcreate_rules() 1087: 1088: Incoming data: three arguments 1089: (a) $dom - domain 1090: (b) $ruleshash - reference to hash containing rules 1091: (a hash of a hash) 1092: keys of top level hash are short names 1093: (e.g., netid) 1094: for each key, value is a hash 1095: desc => long name for rule 1096: rule => description of rule 1097: 1098: (c) $rulesorder - reference to array containing rule names 1099: in order to be displayed 1100: 1101: returns 'ok' if no processing error. 1102: 1103: 1104: =cut 1105: 1106: sub selfcreate_rules { 1107: my ($dom,$ruleshash,$rulesorder) = @_; 1108: my $outcome; 1109: return $outcome; 1110: } 1111: 1112: =pod 1113: 1114: =item username_check() 1115: 1116: Incoming data: four arguments 1117: (a) $dom - domain (scalar) 1118: (b) $uname - username to compare against rules (scalar) 1119: (c) $to_check (reference to array of rule names to check) 1120: (d) $resultshash (reference to hash of results) 1121: hash of results for rule checked 1122: - keys are rule names 1123: - values are: 1 or 0 (for matched or unmatched) 1124: 1125: returns 'ok' if no processing error. 1126: 1127: 1128: =cut 1129: 1130: sub username_check { 1131: my ($dom,$uname,$to_check,$resultshash) = @_; 1132: my $outcome; 1133: return $outcome; 1134: } 1135: 1136: =pod 1137: 1138: =item id_check() 1139: 1140: Incoming data: four arguments 1141: (a) $dom - domain (scalar) 1142: (b) $id - ID to compare against rules (scalar) 1143: (c) $to_check (reference to array of rule names to check) 1144: (d) $resultshash (reference to hash of results) 1145: hash of results for rule checked 1146: - keys are rule names 1147: - values are: 1 or 0 (for matched or unmatched) 1148: 1149: returns 'ok' if no processing error. 1150: 1151: 1152: =cut 1153: 1154: sub id_check { 1155: my ($dom,$id,$to_check,$resultshash) = @_; 1156: my $outcome; 1157: return $outcome; 1158: } 1159: 1160: =pod 1161: 1162: =item selfcreate_check() 1163: 1164: Incoming data: four arguments 1165: (a) $dom - domain (scalar) 1166: (b) $selfcreatename - e-mail proposed as username (compare against rules - scalar) 1167: (c) $to_check (reference to array of rule names to check) 1168: (d) $resultshash (reference to hash of results) 1169: hash of results for rule checked 1170: - keys are rule names 1171: - values are: 1 or 0 (for matched or unmatched) 1172: 1173: returns 'ok' if no processing error. 1174: 1175: 1176: =cut 1177: 1178: sub selfcreate_check { 1179: my ($dom,$selfcreatename,$to_check,$resultshash) = @_; 1180: my $outcome; 1181: return $outcome; 1182: } 1183: 1184: =pod 1185: 1186: =item AUTOLOAD() 1187: 1188: Incoming data: none 1189: Returns '' 1190: 1191: Prevents errors when undefined subroutines are called in this package 1192: Will allow new routines added in the future to be called from lond etc. 1193: without the need for customized versions of local*.pm packages to be 1194: modified to include the new subroutines immediately. 1195: 1196: See "Programming Perl" 3rd ed. pp 296-298. 1197: 1198: =back 1199: 1200: =cut 1201: 1202: sub AUTOLOAD { 1203: our $AUTOLOAD; 1204: return ''; 1205: } 1206: 1207: 1;