loncom/enrollment/localenroll.pm - view

File: [LON-CAPA] / loncom / enrollment / localenroll.pm
Revision 1.64: download - view: text, annotated - select for diffs
Sun Feb 27 01:43:14 2022 UTC (2 years, 2 months ago) by raeburn
Branches: MAIN
CVS tags: version_2_12_X, version_2_11_X, version_2_11_4_uiuc, version_2_11_4_msu, version_2_11_4, HEAD

- Domain configuration to allow authentication of an alternate username, if
  username entered differs from real username in a predictable way,
  e.g., username entered in log-in page was email address (userid@example.tld)
  instead of just userid.

1: # functions to glue school database system into Lon-CAPA for 2: # automated enrollment 3: # $Id: localenroll.pm,v 1.64 2022/02/27 01:43:14 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: =cut 43: 44: package localenroll; 45: 46: use strict; 47: 48: =pod 49: 50: =over 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 student 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 offered 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 optional fourth and fifth arguments - 262: (d) the course co-owners, as a comma-separated list of username:domain for 263: any co-owners. 264: (e) database handle (might be set when new_course() is called by check_section 265: routine within localenroll.pm). 266: 267: =cut 268: 269: sub new_course { 270: my ($course_id,$owner,$dom,$coowners) = @_; 271: my $outcome = 'ok'; 272: return $outcome; 273: } 274: 275: =pod 276: 277: =item validate_courseID() 278: 279: This is called whenever a new course section or crosslisted course 280: is being affiliated with a LON-CAPA course (i.e., by loncreatecourse.pm 281: and the Automated Enrollment Manager in lonpopulate.pm). 282: A check is made that the courseID that the course coordinator wishes 283: to affiliate with the course is valid according to the institutional 284: schedule of official classes 285: 286: A valid courseID is confirmed by returning 'ok' 287: 288: validate_courseID takes two arguments - 289: (a) the institutional courseID (in the MSU case this is a concatenation of 290: semester code, department code, course number, and section number 291: e.g., fs03nop590001). 292: (b) the LON-CAPA domain that contains the course 293: 294: =cut 295: 296: sub validate_courseID { 297: my ($course_id,$dom) = @_; 298: my $outcome = 'ok'; 299: return $outcome; 300: } 301: 302: =pod 303: 304: =item validate_instcode() 305: 306: This is called when a request is being made for an official course. 307: A check is made that the institutional code for which a course is 308: is being requested is valid according to the institutional 309: schedule of official classes. 310: 311: If the username of the course owner is provided, a more restrictive 312: test is used, namely that the requestor is listed as instructor of 313: record for the course in the institution's course schedule/database. 314: 315: validate_instcode takes three arguments - 316: (a) the LON-CAPA domain that will contain the course 317: (b) the institutional code (in the MSU case this is a concatenation of 318: semester code, department code, and course number, e.g., fs03nop590. 319: (c) an optional institutional username for the course owner. 320: 321: An array is returned containing (a) the result of the check for a valid 322: instcode, (b) an (optional) course description, and (c) the default credits 323: earned by students when completing this course. If no institutional credits 324: value is available, the default credits for the course can be set via the 325: course request form, or via XML in a batch file, of via the web form used 326: by the Domain Coordinator to create new courses one at a time. 327: 328: A valid instcode is confirmed by returning 'valid'. 329: 330: If no course description is available, '' should be set as 331: the value of the second item in the returned array. 332: 333: =cut 334: 335: sub validate_instcode { 336: my ($dom,$instcode,$owner) = @_; 337: my $outcome = ''; 338: my $description = ''; 339: my $credits = ''; 340: return ($outcome,$description,$credits); 341: } 342: 343: =pod 344: 345: =item validate_crosslist_access() 346: 347: This is called for an official course to check whether a course 348: with the institutional code can have access to enrollment data 349: from a cross-listed institutional section code, given a co-owner. 350: 351: validate_crosslist_access() takes four arguments - 352: (a) the course's LON-CAPA domain 353: (b) the institional course code assigned to the course 354: (c) the institutional course section code for the crosslisting 355: (d) the co-owner to check for affiliation with the crosslisting 356: (username:domain). 357: 358: A combination of (a), (b), (c) and (d) with access to enrollment 359: data, as per institutional policies, is confirmed by returning 'valid'. 360: 361: =cut 362: 363: sub validate_crosslist_access { 364: my ($dom,$instcode,$inst_xlist,$coowner) = @_; 365: my $outcome = ''; 366: return $outcome; 367: } 368: 369: =pod 370: 371: =item validate_crsreq() 372: 373: This is used to check whether a course request should be processed 374: automatically, or held in a queue pending administrative action at 375: the institution. 376: 377: Course requests will trigger this check if the process type has been set 378: to 'validate' for the course type (official, unofficial, textbook, 379: placement or community) and the requestor's affiliation. Whether 380: "validate" is an available option in the Domain Configuration menu 381: is controlled by auto_courserequest_checks(). 382: One scenario is where the request is for an official course, in which case 383: a check could be made that the requestor is listed as instructor of 384: record for the course in the institution's course schedule/database. 385: 386: Other scenarios are possible, and the routine can be customized according 387: to whatever rules a domain wishes to implement to run validations against 388: given the data passed in to the routine. 389: 390: validate_crsreq takes seven arguments - 391: (a) the LON-CAPA domain that will contain the course. 392: (b) the username:domain for the course owner. 393: (c) the course type (official, unofficial,textbook, placement or community) 394: (d) a comma-separated list of institutional affiliations of 395: the course owner. 396: (e) the institutional code (in the MSU case this is a concatenation of 397: semester code, department code, and course number, e.g., fs03nop590). 398: (f) a comma-separated list of institutional sections included in 399: the course request (only applicable to official courses). 400: (g) an optional reference to a hash of custom form data. 401: The custom form data will come from crsreq_updates(), with one 402: additional item: $custominfo->{'_LC_clonefrom'}, provided internally 403: (the courseID of the LON-CAPA course being cloned). 404: 405: A valid courserequest is confirmed by returning 'process'. 406: The following can be returned: process, rejected, pending, approval or 407: error (with error condition - no :), followed by a : and then an optional message. 408: 409: (a) process - the requestor is the recorded instructor - create the course 410: 411: (b) rejected - the requestor should never be requesting this course, reject the 412: request permanently 413: 414: (c) pending - the requestor is not the recorded instructor, but could 415: become so after administrative action at the institution. Put the 416: request in a queue and, if an official course, check 417: localenroll:validate_instcode() periodically until the status changes to 418: "valid". 419: 420: (d) approval - the request will be held pending review by a Domain Coordinator. 421: 422: (e) error (followed by the error condition). 423: 424: =cut 425: 426: sub validate_crsreq { 427: my ($dom,$owner,$crstype,$inststatuslist,$instcode,$instseclist,$custominfo) = @_; 428: my $outcome = 'approval'; 429: return $outcome; 430: } 431: 432: =pod 433: 434: =item crsreq_checks() 435: 436: This is used to determine whether the "validate" option should appear in the 437: possible choices for course request processing in the Domain Configuration 438: menu for Course Requests. Ultimately it is called by domainprefs.pm (via: 439: lonnet -> lond -> localenroll.pm) The domain configuration menu includes 440: a table where columns are course type (official, unofficial, textbook, 441: placement or community) and rows are institutional affiliations 442: (e.g., Faculty, Staff, Student etc.). 443: 444: crsreq_checks() takes three arguments: $dom, $reqtypes, $validations. 445: $dom - the domain for which validation options are needed. 446: $reqtypes - ref to an ARRAY of course types (i.e., official, unofficial and community. 447: $validations - ref to a hash of a hash which will determine whether "validate" 448: will be one of the possible choices for each course type (outer hash key), 449: and institutional type (inner hash key). 450: 451: For example to allow validate to be a choice for official classes for Faculty, 452: req_checks would include: 453: 454: $validations{'official'}{'Faculty'} = 1; 455: 456: This routine is closely tied to validate_crsreq(). "Validate" should not be 457: a possible choice in the domain configuration menu for a particular course 458: type/institutional affiliation, unless a corresponding validation code has 459: been implemented in validate_crsreq(). 460: 461: For example at MSU, official courses requested by Faculty will be validated 462: against the official schedule of classes to check that the requestor is one 463: of the instructors of record for the course. In this case validate_crsreq() 464: includes a call to validate_instcode(). 465: 466: =cut 467: 468: sub crsreq_checks { 469: my ($dom,$reqtypes,$validations) = @_; 470: if ((ref($reqtypes) eq 'ARRAY') && (ref($validations) eq 'HASH')) { 471: my (%usertypes,@order); 472: if (&inst_usertypes($dom,\%usertypes,\@order) eq 'ok') { 473: foreach my $type (@{$reqtypes}) { 474: foreach my $inst_type (@order) { 475: $validations->{$type}{$inst_type} = 0; 476: } 477: } 478: } 479: } 480: return 'ok'; 481: } 482: 483: =pod 484: 485: =item crsreq_updates() 486: 487: This is used to customize the LON-CAPA course request process. 488: There are two hash references: $incoming, and $outgoing; $incoming can 489: contain additional information collected from the requester, whereas $outgoing 490: can contain custom items to send back to lonrequestcourse.pm, which creates the 491: HTML displayed to the user during a course request. 492: 493: Different key-value pairs may be returned to lonrequestcourse.pm in the $outgoing 494: hashref depending on the current action. The available actions are: 495: review, prevalidate, process, created and queued. 496: 497: One scenario would be to return HTML markup in: $outgoing->{'reviewweb'}, 498: i.e., where the action is 'review', to prompt the user to provide additional 499: information as part of the course request, at the request review stage, 500: (i.e,, the page which contains the button used to submit a completed course request). 501: 502: The HTML could contain form elements (e.g., radio buttons etc.). The value(s) 503: selected by the requester in those form elements will be available in the incoming 504: hashref, for a subsequent action, if the corresponding keys have been included 505: in $outgoing->{'formitems'}, i.e., $outgoing will be hash of a hash. If a 506: particular form item will the single valued, the value set for the key in the 507: inner hash in $outgoing should be 1, otherwise, if it will be multi-valued, 508: the value should be multiple. 509: 510: The $outgoing hashref can contain a 'formitems' key for both the prevalidate 511: and process actions, as calls to localenroll::crsreq_update() can originate 512: in lonrequestcourse::process_request() for both of those actions. 513: 514: The retrieved form values are passed to localenroll::validate_crsreq() as the 515: optional seventh arg (a hashref) -- $custominfo. 516: 517: =cut 518: 519: sub crsreq_updates { 520: my ($cdom,$cnum,$crstype,$action,$ownername,$ownerdomain,$fullname,$title, 521: $code,$accessstart,$accessend,$incoming,$outgoing) = @_; 522: unless (ref($outgoing) eq 'HASH') { 523: return 'fail'; 524: } 525: my %extrainfo; 526: if (ref($incoming) eq 'HASH') { 527: %extrainfo = %{$incoming}; 528: } 529: if ($action eq 'review') { 530: $outgoing->{'reviewweb'} = ''; 531: } elsif ($action eq 'prevalidate') { 532: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name 533: # and value is multiple, if there 534: # are multiple form elements with 535: # the same name. 536: } elsif ($action eq 'process') { 537: $outgoing->{'formitems'} = {}; # key=>value, where key is form element name 538: # and value is multiple, if there 539: # are multiple form elements with 540: # the same name. 541: } elsif ($action eq 'created') { 542: $outgoing->{'createdweb'} = ''; 543: $outgoing->{'createdmsg'} = [{ 544: mt => '', 545: args => [], 546: }]; 547: $outgoing->{'createdactions'} = { 548: environment => {}, 549: }; 550: # environment can contain key=>value for 551: # items to set in the course environment. 552: # These would be items which are NOT included 553: # in the items set via options in the course 554: # request form. Currently self-enrollment 555: # settings are the only ones allowed, i.e., 556: # internal.selfenroll_types internal.selfenroll_registered 557: # internal.selfenroll_section internal.selfenroll_start_access 558: # internal.selfenroll_end_access internal.selfenroll_limit 559: # internal.selfenroll_cap internal.selfenroll_approval 560: # internal.selfenroll_notifylist 561: } elsif ($action eq 'queued') { 562: $outgoing->{'queuedmsg'} = [{ 563: mt => '', 564: args => [], 565: }]; 566: $outgoing->{'queuedweb'} = ''; 567: } 568: return 'ok' 569: } 570: 571: =pod 572: 573: =item export_grades() 574: 575: This routine can be customized to push grade information to some other gradebook, 576: LCMS, or administrative system external to LON-CAPA. 577: 578: export_grades() takes five arguments - 579: (a) the LON-CAPA course ID 580: (b) the LON-CAPA course domain 581: (c) a hash reference containing the following: 582: scope => scope of the grades (e.g., course, map or resource). 583: instcode => institutional course code (if an official course) 584: crstype => course type -- Course, Community or Placement 585: context => calling context, e.g., "completion" when a student completes a placement test. 586: (d) a perl data structure (hash of a hash) containing the grade data. 587: in the outer hash, the keys are student's username:domain 588: in the inner hash, keys are: 589: id => student/employee ID 590: lastname => student's last name 591: firstname => student's first name 592: email => student's "permannent" e-mail address 593: section => student's LON-CAPA course section 594: total => total points earned 595: bytitle => reference to a hash (keys are question titles, values are points 596: bysymb => reference to a hash (keys are symbs, i.e., unique resource identifiers). 597: (e) reference to a hash which will contain information to return. 598: keys will be the student's username:domain. Value of 1 to show grades pushed 599: successfully. 600: 601: =cut 602: 603: sub export_grades { 604: my ($cnum,$cdom,$hashref,$dataref,$outgoing) = @_; 605: my %info; 606: if (ref($hashref) eq 'HASH') { 607: %info = %{$hashref}; 608: } 609: if ((ref($dataref) eq 'HASH') && (ref($outgoing) eq 'HASH')) { 610: foreach my $key (keys(%{$dataref})) { 611: $outgoing->{$key} = 1; 612: } 613: return 'ok'; 614: } else { 615: return 'error'; 616: } 617: } 618: 619: =pod 620: 621: =item check_instclasses() 622: 623: This is used to supply information about which instituional course sections 624: and cross-listings are available to supply enrollment data, given the current 625: list of owner and co-owners. The data are used to populate the column titled: 626: "Auto-enrollment of registered students" when showing full detailed for a course 627: in the course catalog. 628: 629: This subroutine takes four arguments - 630: 631: (a) $owners - comma-separated list of username:domain for course owner 632: and co-owners. 633: (b) $dom - domain of course. 634: (c) $classes - reference to hash of institutional course sections and 635: crosslistings for which access to enrollment data is being checked. 636: (d) $validated - reference to hash which will be populated with all 637: keys from incoming $classes hashref, for which one or more of the 638: owner/co-owners has rights to access enrollment data. For each 639: key included in $validated hashref, corresponding value will be set to 1. 640: 641: The subroutine returns 'ok' if there is no processing error. 642: 643: =cut 644: 645: 646: sub check_instclasses { 647: my ($owners,$dom,$classes,$validated) = @_; 648: if ((ref($classes) eq 'HASH') && (ref($validated) eq 'HASH')) { 649: foreach my $class (keys(%{$classes})){ 650: if (&check_section($class,$owners,$dom) eq 'ok') { 651: $validated->{$class} = 1; 652: } 653: } 654: } 655: return 'ok'; 656: } 657: 658: =pod 659: 660: =item instsec_reformat() 661: 662: Inputs: $dom, $action, $instsecref 663: 664: $dom is the course's domain 665: $action is either: clutter or declutter 666: $instsecref is a reference to a hash, in which each key is 667: course num:course code, and each value is either an array of 668: institutional sections, or (in the case of crosslisted courses) 669: an array of institutional course sections. 670: 671: Returns: ok 672: 673: Side effects: will modify the items in the array as determined by 674: code implemented for the domain. Modification will differ depending 675: on whether the action is clutter or declutter. 676: 677: The idea is that "clutter" will modify the name of the section such 678: that a concatenation of institutional code then (modified) section 679: will result in a string that other customized routines in localenroll.pm 680: can separate without ambiguity into instituional code then (real) 681: institutional section using a regular expression. 682: 683: Conversely, "declutter" will modify the name of an already modified 684: item such that display of the concatenated string (e.g., for a 685: crosslisting in the course catalog) does not include the "added" 686: characters used to eliminate ambiguity. 687: 688: Examples (MSU): 689: 690: Starting in Fall 2021 at MSU, institution section numbers are no 691: longer guaranteed to be three digit numbers (including leading zeroes). 692: 693: So, for example the course code: fs21phy183b might have sections: 694: 001, 002, LEC1, LEC2, and be crosslisted with fs21phy233b (with 695: sections: 730, LEC3, LEC4). 696: 697: The sections: LEC1, and LEC2 should be changed to _LEC1, and _LEC2 698: before creating the inner keys in the %affiliates hash of a hash, 699: passed to fetch_enrollment() in Enrollment.pm. They will however 700: be stored in the course's environment as LEC1 and LEC2. 701: 702: For the crosslistings, LEC3 and LEC4 should be changed to 703: _LEC3 and _LEC4 before storing in the course's environment.db file. 704: 705: In both cases when it comes time to extract the various components 706: of an institutional section code (i.e., the concatenated string) in 707: fetch_enrollment(), for example, the regexp used at MSU would be: 708: 709: if ($class =~ m/^([suf]s)(\d{2})(\w{2,4})(\d{3,4}[A-Za-z]?)(\d{3}|_[A-Za-z0-9]{1,5})$/) { 710: my ($sem,$yr,$subj,$crse,$sec) = ($1,$2,$3,$4,$5); 711: 712: The three digit sections would match the \d{3} and the other sections 713: (LEC1, LEC2 etc.) would match the _[A-Za-z0-9]{1,5}. 714: 715: The customization in &instsec_reformat() would be: 716: 717: if ($action eq 'clutter') { 718: unless ($item =~ /^\d{3}$/) { 719: $item = '_'.$item; 720: } 721: } elsif ($action eq 'declutter') { 722: if ($item =~ /^([suf]s\d{2}\w{2,4}\d{3,4}[A-Za-z]?)(\d{3}|_[A-Za-z0-9]{1,5})$/) { 723: my ($instcode,$instsec) = ($1,$2); 724: $instsec =~ s/^_//; 725: $item = $instcode.$instsec; 726: } elsif ($item =~ /^_[A-Za-z0-9]{1,5}$/) { 727: $item =~ s/^_//; 728: } 729: } 730: 731: =cut 732: 733: sub instsec_reformat { 734: my ($dom,$action,$instsecref) = @_; 735: if ((ref($instsecref) eq 'HASH') && 736: (($action eq 'clutter') || ($action eq 'declutter'))) { 737: foreach my $key (keys(%{$instsecref})) { 738: if (ref($instsecref->{$key}) eq 'ARRAY') { 739: foreach my $sec (@{$instsecref->{$key}}) { 740: if ($action eq 'clutter') { 741: # modify the section, as needed. 742: next; 743: } elsif ($action eq 'declutter') { 744: # modify the section, as needed. 745: next; 746: } 747: } 748: } 749: } 750: } 751: return 'ok'; 752: } 753: 754: =pod 755: 756: =item create_password() 757: 758: This is called when the authentication method set for the automated 759: enrollment process when enrolling new users in the domain is "localauth". 760: This could be signalled for the specific user by the value of localauth 761: for the <authtype> tag from the classlist.xml files, or if this is blank, 762: the default authtype, set by the domain coordinator when creating the course 763: with loncreatecourse.pm. 764: 765: create_password takes three arguments - 766: (a) $authparam - the value of <autharg> from the classlist.xml files, 767: or if this blank, the default autharg, set by the domain coordinator when 768: creating the course with loncreatecourse.pm 769: (b) $dom - the domain of the new user. 770: (c) $username - the username of the new user (currently not actually used) 771: 772: Four values are returned: 773: (a) the value of $authparam - which might have been changed 774: (b) a flag to indicate whether a password had been created 775: 0 means no password created 776: 1 means password created. In this case the calling module - Enrollment.pm 777: will send the LON-CAPA username and password to the new user's e-mail 778: (if one was provided), or to the course owner (if one was not provided and 779: the new user was created by the automated process), or to the active 780: course coordinator (if the new user was created using the 'update roster 781: now' interface included in the Automated Enrollment Manager). 782: (c) a flag to indicate that the authentication method is correct - 'ok'. 783: If $authchk is not set to 'ok' then account creation and enrollment of the 784: new user will not occur. 785: (d) if a password was created it can be sent along. This is the password 786: which will be included in the e-mail sent to the new user, or made available 787: to the course owner/course coordinator if no e-mail address is provided. If 788: you do not wish to send a password, but want to give instructions on obtaining 789: one, you could set $newpasswd as those instructions. (e.g., 790: $newpasswd = '(Please visit room 212, ACNS Bldg. to obtain your password)'; 791: The value of $newpasswd is NOT written in the user's LON-CAPA passwd file in 792: /home/httpd/lonUsers/$dom/a/b/c/abcuser/passwd, which in the case of a user 793: employing localauth will contain 'localauth:$authparam'. If you need to include 794: a parameter in the user's passwd file, you should return it as $authparam, 795: i.e., the first of the variables returned by create_password(). 796: 797: 798: =cut 799: 800: sub create_password { 801: my ($authparam,$dom,$username) = @_; 802: my $authchk = 'ok'; 803: my $newpasswd = ''; 804: my $create_passwd = 0; 805: return ($authparam,$create_passwd,$authchk,$newpasswd); 806: } 807: 808: =pod 809: 810: =item instcode_format() 811: 812: Split coursecodes into constituent parts. 813: e.g., INSTITUTIONALCODE = fs03nop590, LON-CAPA COURSEID: 43551dedcd43febmsul1 814: (MSU's course naming scheme - fs03 = Fall semester 2003, nop = 815: department name, 590 = course number) 816: 817: Incoming data: 818: $dom (domain) 819: $$instcodes{'43551dedcd43febmsul1'} = 'fs03nop590' (hash of courseIDs) 820: 821: fs03nop590 would be split as follows 822: @{$codetitles} = ("year","semester","department","number") 823: $$codes{'year'} = '2003' 824: $$codes{'semester'} = 'Fall' 825: $$codes{'department'} = 'nop' 826: $$codes{'number'} = '590' 827: 828: requires six arguments: 829: domain ($dom) 830: reference to hash of institutional course IDs ($instcodes) 831: reference to hash of codes ($codes) 832: reference to array of titles ($codetitles) 833: reference to hash of abbreviations used in categories 834: reference to hash of arrays specifying sort order used in category titles 835: 836: e.g., %{$$cat_titles{'Semester'}} = ( 837: fs => 'Fall', 838: ss => 'Spring', 839: us => 'Summer'); 840: 841: e.g., @{$$cat_order{'Semester'}} = ('ss','us','fs'); 842: returns 1 parameter: 'ok' if no processing errors. 843: 844: Detailed help: 845: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp 846: 847: =cut 848: 849: 850: sub instcode_format () { 851: my ($dom,$instcodes,$codes,$codetitles,$cat_titles,$cat_order) = @_; 852: my $outcome = 'ok'; 853: return $outcome; 854: } 855: 856: =pod 857: 858: =item possible_instcodes() 859: 860: Gather acceptable values for institutional categories to use in course creation request form for official courses. 861: 862: requires five arguments: 863: 864: domain ($dom) 865: reference to array of titles ($codetitles) 866: reference to hash of abbreviations used in categories ($cat_titles). 867: reference to hash of arrays specifying sort order used in 868: category titles ($cat_order). 869: reference to array which will contain order of component parts used 870: in institutional code ($code_order). 871: 872: e.g., 873: @{$codetitles} = ('Year','Semester',"Department','Number'); 874: 875: %{$$cat_titles{'Semester'}} = ( 876: fs => 'Fall', 877: ss => 'Spring', 878: us => 'Summer'); 879: 880: @{$$cat_order{'Semester'}} = ('ss','us','fs'); 881: @{$code_order} = ('Semester','Year','Department','Number'); 882: 883: returns 1 parameter: 'ok' if no processing errors. 884: 885: =cut 886: 887: sub possible_instcodes { 888: my ($dom,$codetitles,$cat_titles,$cat_order,$code_order) = @_; 889: @{$codetitles} = (); 890: %{$$cat_titles{'Semester'}} = (); 891: @{$$cat_order{'Semester'}} = ('ss','us','fs'); 892: @{$code_order} = (); 893: return 'ok'; 894: } 895: 896: 897: =pod 898: 899: =item institutional_photos() 900: 901: Called when automated enrollment manager is used to update student photos. 902: 903: Incoming data: six arguments 904: (a) $dom (domain) 905: (b) $crs (LONCAPA course number) 906: (c) $affiliates: a reference to a hash with the keys set to the 907: institutional course IDs for the course. 908: (d) $result: a reference to a hash which will return usernames 909: of students (& separated) in following categories (the keys): 910: new, update, missing, same, deleted, noid, nouser. The list 911: includes those students for whom the result of the modification 912: process was either addition of a new photo. update of an 913: existing photo, photo was found to be missing from institution's 914: data store, photo used is same as before, or photo was 915: deleted from storage on LON-CAPA server housing student's 916: information, no student/employee ID was available. 917: 918: (e) $action: the type of action needed. (e.g., update, delete); 919: (f) $students: a reference to a hash with the keys set to student 920: usernames and domains in the form username:domain, and values set 921: to the studentID, if action is required for specific students. 922: 923: returns 1 parameter: 'ok' if no processing errors. 924: other course or student specific values can be stored as values 925: in the appropriate referenced hashes. 926: 927: =cut 928: 929: sub institutional_photos { 930: my ($dom,$crs,$affiliates,$result,$action,$students) = @_; 931: my $outcome = 'ok'; 932: return $outcome; 933: } 934: 935: =pod 936: 937: =item photo_permission() 938: 939: Incoming data: three arguments 940: (a) $dom (domain) 941: (b) $perm_reqd: a reference to a a scalar that is either 'yes' 942: if a course owner must indicate acceptance of conditions of use, 943: 'no' otherwise. 944: (c) $conditions: the text of the conditions of use. 945: 946: returns 1 parameter: 'ok' if no processing errors. 947: $$perm_reqd is set to 'yes' or 'no' 948: $$agreement is set to conditions of use - plain text string 949: which will be displayed in a textarea in a web form. 950: 951: 952: =cut 953: 954: sub photo_permission { 955: my ($dom,$perm_reqd,$conditions) = @_; 956: $$perm_reqd = 'no'; 957: $$conditions = ''; 958: my $outcome = 'ok'; 959: return $outcome; 960: } 961: 962: =pod 963: 964: =item manager_photo_update() 965: 966: Incoming data: one argument 967: (a) $dom (domain) 968: 969: returns 2 parameters: update (0 or 1), and comment. 970: Called by automated enrollment manager, to determine 971: whether "Update Student photos" button will be available, 972: and if so, the message (plain text string) that will be displayed 973: with the button. 974: 975: 976: =cut 977: 978: sub manager_photo_update { 979: my ($dom) = @_; 980: my $update = 0; 981: my $comment = ''; 982: return ($update,$comment); 983: } 984: 985: =pod 986: 987: 988: =item check_section() 989: 990: Incoming data: three arguments (+ fourth optional argument) 991: (a) $class - institutional class id (coursecode concatanated with section) 992: (b) $owner - course owner (2.2 and later username:domain; pre-2.2 username; 993: 2.6 and later - comma-separated list of 994: username:domain for course owner and co-owners.) 995: (c) $dom - domain of course 996: (d) $dbh - optional database handle 997: 998: returns 1 parameter - $sectioncheck ('ok' or other value). 999: Verifies that at least one of the course owner (or co-owners) have access 1000: to classlist for specific class according to institution's SIS 1001: 'ok' if access available 1002: 1003: 1004: =cut 1005: 1006: sub check_section { 1007: my ($class,$owner,$dom,$dbh) = @_; 1008: my $sectioncheck = 'ok'; 1009: return $sectioncheck; 1010: } 1011: 1012: =pod 1013: 1014: =item instcode_defaults() 1015: 1016: Incoming data: three arguments 1017: (a) $dom - domain 1018: (b) $defaults - reference to hash which will contain default regular 1019: expression matches for different components of an 1020: institutional course code 1021: (c) $code_order - reference to array which will contain order of 1022: component parts used in institutional code. 1023: 1024: returns 1 parameter - ('ok' or other value). 1025: Used to construct a regular expression to be used when searching for 1026: courses based on fragments of an institutional code. 1027: $defaults contains defaults to use for each component, and code_order 1028: contains keys of hash in order in which they are to be concatenated. 1029: 1030: e.g., INSTITUTIONALCODE = fs03nop590 1031: (MSU's course naming scheme - fs = semester, 03 = year, nop = 1032: department name, 590 = course number) 1033: 1034: %{$defaults} = ( 1035: 'Year' => '\d{2}', 1036: 'Semester' => '^[sfu]s', 1037: 'Department' => '\w{2,3}', 1038: 'Number' => '\d{3,4}\w?', 1039: ); 1040: 1041: @{$code_order} = ('Semester','Year','Department','Number'); 1042: 1043: Detailed help: 1044: http://yourloncapaserver/adm/help/Institutional_Integration_Course_Codes.hlp 1045: 1046: =cut 1047: 1048: sub instcode_defaults { 1049: my ($dom,$defaults,$code_order) = @_; 1050: return 'ok'; 1051: } 1052: 1053: 1054: =pod 1055: 1056: =item allusers_info() 1057: 1058: Incoming data: three arguments 1059: (a) $dom - domain 1060: (b) $instusers - reference to hash which will contain hashes, 1061: where keys will be usernames and value will be a 1062: hash of user information. Keys in the inner hash 1063: will be some or all of: lastname,firstname, 1064: middlename, generation, id, inststatus - 1065: institutional status (e.g., faculty,staff,student) 1066: Values are all scalars except inststatus, 1067: which is an array. 1068: (c) $instids - reference to hash which will contain ID numbers. 1069: keys will be unique IDs (student or faculty/staff ID) 1070: values will be either: scalar (username) or an array 1071: if a single ID matches multiple usernames. 1072: (d) $lc_users - reference to hash containing LON-CAPA usernames in 1073: in domain $dom, as keys. Needed if institutional 1074: data source only allows query by username. 1075: (e) $counts - reference to hash (optional), for use when called 1076: from Autoupdate.pl which can contain counts for 1077: user-specified items retrieved in allusers_info() 1078: or in custom subroutines which it calls. Key in 1079: hashref, and count value will be printed to 1080: autoupdate.log by Autoupdate.pl. 1081: 1082: returns 1 parameter - 'ok' if no processing error, or other value 1083: if an error occurred. 1084: side effects - populates the $instusers and $instids refs to hashes. 1085: with information for all users from all available 1086: institutional datafeeds. 1087: 1088: 1089: =cut 1090: 1091: sub allusers_info { 1092: my ($dom,$instusers,$instids,$lc_users,$counts) = @_; 1093: my $outcome = 'ok'; 1094: return $outcome; 1095: } 1096: 1097: =pod 1098: 1099: =item get_userinfo() 1100: 1101: Incoming data: four required arguments and additional optional arguments 1102: Two modes of operation: 1103: (1) Retrieves institutional data for a single user either by username 1104: if $uname is included as second argument, or by ID if $id is 1105: included as a third argument. Either (b) or (c) must be provided. 1106: (g), (h) and (i) will be undefined. 1107: (2) Retrieves institutional user data from search of an institutional 1108: directory based on a search. (g) and (h) are required. 1109: (i) is optional. (b) and (c) will be undefined. 1110: 1111: (a) $dom - domain 1112: (b) $uname - username of user 1113: (c) $id - student/faculty ID of user 1114: (d) $instusers - reference to hash which will contain info for user 1115: as key = value; keys will be one or all of: 1116: lastname,firstname,middlename,generation,id,inststatus - 1117: institutional status (e.g., faculty,staff,student) 1118: Values are all scalars except inststatus, 1119: which is an array. 1120: (e) $instids - reference to hash which will contain ID numbers - 1121: keys will be unique IDs (student or faculty/staff ID) 1122: values will be either: scalar (username) or an array 1123: if a single ID matches multiple usernames. 1124: (f) $types - optional reference to array which contains 1125: institutional types to check. 1126: (g) $srchby - optional if $uname or $id defined, otherwise required. 1127: Allowed values include: 1. lastfirst, 2. last, 3. uname 1128: 4. email, corresponding to searches by 1. lastname,firstname; 1129: 2. lastname; 3. username; 4. e-mail address 1130: (h) $srchterm - optional if $uname or $id defined, otherwise required 1131: String to search for. 1132: (i) $srchtype - optional. Allowed values: contains, begins (defaults 1133: to exact match otherwise). 1134: 1135: returns 1 parameter - 'ok' if no processing error, or other value 1136: if an error occurred. 1137: side effects - populates the $instusers and $instids refs to hashes. 1138: with information for specified username, or specified 1139: id, if fifth argument provided, from all available, or 1140: specified (e.g., faculty only) institutional datafeeds, 1141: if sixth argument provided. 1142: 1143: WARNING: You need to set $outcome to 'ok' once you have customized 1144: this routine to communicate with an instititional 1145: directory data source, otherwise institutional directory 1146: searches will always be reported as being unavailable 1147: in domain $dom. 1148: 1149: =cut 1150: 1151: sub get_userinfo { 1152: my ($dom,$uname,$id,$instusers,$instids,$types, 1153: $srchby,$srchterm,$srchtype) = @_; 1154: my $outcome = 'unavailable'; 1155: return $outcome; 1156: } 1157: 1158: =pod 1159: 1160: =item get_multusersinfo() 1161: 1162: (a) $dom - domain 1163: (b) $type - username or id 1164: (c) $unamenames - reference to hash containing usernames of users 1165: (d) $instusers - reference to hash which will contain info for user 1166: as key = value; keys will be one or all of: 1167: lastname,firstname,middlename,generation,id,inststatus - 1168: institutional status (e.g., faculty,staff,student) 1169: Values are all scalars except inststatus, 1170: which is an array. 1171: (e) $instids - reference to hash which will contain ID numbers - 1172: keys will be unique IDs (student or faculty/staff ID) 1173: values will be either: scalar (username) or an array 1174: if a single ID matches multiple usernames. 1175: 1176: returns 1 parameter - 'ok' if no processing error, or other value 1177: if an error occurred. 1178: 1179: side effects - populates the $instusers and $instids refs to hashes. 1180: with information for specified username, or specified 1181: id, if fifth argument provided, from all available, or 1182: specified (e.g., faculty only) institutional datafeeds, 1183: if sixth argument provided. 1184: 1185: WARNING: You need to set $outcome to 'ok' once you have customized 1186: this routine to communicate with an instititional 1187: directory data source, otherwise retrieval of institutional 1188: user information will always be reported as being unavailable 1189: in domain $dom. 1190: 1191: =cut 1192: 1193: sub get_multusersinfo { 1194: my ($dom,$type,$usernames,$instusers,$instids) = @_; 1195: my $outcome = 'unavailable'; 1196: return $outcome; 1197: } 1198: 1199: =pod 1200: 1201: =item inst_usertypes() 1202: 1203: Starting with LON-CAPA 2.11.0 use of this subroutine 1204: is deprecated. The domain configuration web GUI 1205: accessible to Domain Coordinators will be used to 1206: manage institutional types. If you have previously 1207: customized this routine, then values set there will 1208: be used when displaying the "Institutional user types" 1209: section in the domain config screen for: 1210: "Default authentication/language/timezone/portal/types". 1211: 1212: Once you have visited that screen and saved the settings, 1213: configuration thereafter will be via the web GUI of 1214: values stored in the domain's configuration.db file on 1215: the primary library server in the domain, and values in 1216: inst_usertypes() will no longer be consulted. 1217: 1218: Incoming data: three arguments 1219: (a) $dom - domain 1220: (b) $usertypes - reference to hash which will contain 1221: key = value, where keys are institution 1222: affiliation types (e.g., Faculty, Student etc.) 1223: and values are titles (e.g., Faculty/Academic Staff) 1224: (c) $order - reference to array which will contain the order in 1225: which institutional types should be shown 1226: when displaying data tables (e.g., default quotas 1227: or updateable user fields (see domainprefs.pm) 1228: returns 1 parameter - 'ok' if no processing error, or other value 1229: if an error occurred. 1230: 1231: 1232: =cut 1233: 1234: sub inst_usertypes { 1235: my ($dom,$usertypes,$order) = @_; 1236: @{$order} = (); 1237: %{$usertypes} = (); 1238: my $outcome = 'ok'; 1239: return $outcome; 1240: } 1241: 1242: =pod 1243: 1244: =item username_rules() 1245: 1246: Incoming data: three arguments 1247: (a) $dom - domain 1248: (b) $ruleshash - reference to hash containing rules 1249: (a hash of a hash) 1250: keys of top level hash are short names 1251: (e.g., netid, noncredit) 1252: for each key, value is a hash 1253: name => long name for rule 1254: desc => description of rule 1255: authtype => (krb5,krb4,int, or loc) 1256: authentication type for rule 1257: authparm => authentication parameter for rule 1258: authparmfixed => 1 if authparm used when 1259: creating user for rule must be authparm 1260: authmsg => Message to display describing 1261: authentication to use for this rule 1262: 1263: (c) $rulesorder - reference to array containing rule names 1264: in order to be displayed 1265: 1266: 1267: returns 'ok' if no processing error. 1268: 1269: =cut 1270: 1271: sub username_rules { 1272: my ($dom,$ruleshash,$rulesorder) = @_; 1273: my $outcome; 1274: return $outcome; 1275: } 1276: 1277: =pod 1278: 1279: =item id_rules() 1280: 1281: Incoming data: three arguments 1282: (a) $dom - domain 1283: (b) $ruleshash - reference to hash containing rules 1284: (a hash of a hash) 1285: keys of top level hash are short names 1286: (e.g., netid, noncredit) 1287: for each key, value is a hash 1288: name => long name for rule 1289: desc => description of rule 1290: 1291: (c) $rulesorder - reference to array containing rule names 1292: in order to be displayed 1293: 1294: returns 'ok' if no processing error. 1295: 1296: =cut 1297: 1298: sub id_rules { 1299: my ($dom,$ruleshash,$rulesorder) = @_; 1300: my $outcome; 1301: return $outcome; 1302: } 1303: 1304: =pod 1305: 1306: =item selfcreate_rules() 1307: 1308: Incoming data: three arguments 1309: (a) $dom - domain 1310: (b) $ruleshash - reference to hash containing rules 1311: (a hash of a hash) 1312: keys of top level hash are short names 1313: (e.g., netid) 1314: for each key, value is a hash 1315: name => long name for rule 1316: desc => description of rule 1317: 1318: (c) $rulesorder - reference to array containing rule names 1319: in order to be displayed 1320: 1321: returns 'ok' if no processing error. 1322: 1323: 1324: =cut 1325: 1326: sub selfcreate_rules { 1327: my ($dom,$ruleshash,$rulesorder) = @_; 1328: my $outcome; 1329: return $outcome; 1330: } 1331: 1332: =pod 1333: 1334: =item unamemap_rules() 1335: 1336: Incoming data: three arguments 1337: (a) $dom - domain 1338: (b) $ruleshash - reference to hash containing rules 1339: (a hash of a hash) 1340: keys of top level hash are short names 1341: (e.g., netid) 1342: for each key, value is a hash 1343: name => long name for rule 1344: desc => description of rule 1345: 1346: For example: 1347: 1348: %{$ruleshash} = ( 1349: emailaddress => { 1350: name => 'Email address to UserID', 1351: desc => 'Extract userID from userID@example.tld', 1352: }, 1353: ); 1354: would enable display of a checkbox for: 'Email address to UserID' in the 1355: "Available conversions" item in the "Mapping for missing usernames via standard log-in" 1356: panel available to a Domain Coordinator via: 1357: Main Menu > Set domain configuration > Display ("Default authentication/language/timezone/portal/types" checked) 1358: 1359: (c) $rulesorder - reference to array containing rule names 1360: in order to be displayed 1361: 1362: returns 'ok' if no processing error. 1363: 1364: =cut 1365: 1366: sub unamemap_rules { 1367: my ($dom,$ruleshash,$rulesorder) = @_; 1368: my $outcome; 1369: return $outcome; 1370: } 1371: 1372: =pod 1373: 1374: =item username_check() 1375: 1376: Incoming data: four arguments 1377: (a) $dom - domain (scalar) 1378: (b) $uname - username to compare against rules (scalar) 1379: (c) $to_check (reference to array of rule names to check) 1380: (d) $resultshash (reference to hash of results) 1381: hash of results for rules checked 1382: - keys are rule names 1383: - values are: 1 or 0 (for matched or unmatched) 1384: 1385: returns 'ok' if no processing error. 1386: 1387: 1388: =cut 1389: 1390: sub username_check { 1391: my ($dom,$uname,$to_check,$resultshash) = @_; 1392: my $outcome; 1393: return $outcome; 1394: } 1395: 1396: =pod 1397: 1398: =item id_check() 1399: 1400: Incoming data: four arguments 1401: (a) $dom - domain (scalar) 1402: (b) $id - ID to compare against rules (scalar) 1403: (c) $to_check (reference to array of rule names to check) 1404: (d) $resultshash (reference to hash of results) 1405: hash of results for rules checked 1406: - keys are rule names 1407: - values are: 1 or 0 (for matched or unmatched) 1408: 1409: returns 'ok' if no processing error. 1410: 1411: 1412: =cut 1413: 1414: sub id_check { 1415: my ($dom,$id,$to_check,$resultshash) = @_; 1416: my $outcome; 1417: return $outcome; 1418: } 1419: 1420: =pod 1421: 1422: =item selfcreate_check() 1423: 1424: Incoming data: four arguments 1425: (a) $dom - domain (scalar) 1426: (b) $selfcreatename - e-mail proposed as username (compare against rules - scalar) 1427: (c) $to_check (reference to array of rule names to check) 1428: (d) $resultshash (reference to hash of results) 1429: hash of results for rules checked 1430: - keys are rule names 1431: - values are: 1 or 0 (for matched or unmatched) 1432: 1433: returns 'ok' if no processing error. 1434: 1435: 1436: =cut 1437: 1438: sub selfcreate_check { 1439: my ($dom,$selfcreatename,$to_check,$resultshash) = @_; 1440: my $outcome; 1441: return $outcome; 1442: } 1443: 1444: =pod 1445: 1446: =item unamemap_check() 1447: 1448: Incoming data: four arguments 1449: (a) $dom - domain (scalar) 1450: (b) $uname - username entered on log-in page (compare against rules - scalar) 1451: (c) $to_check (reference to array of rule names to check) 1452: (d) $resultshash (reference to hash of results) 1453: hash of results for rules checked 1454: - keys are rule names 1455: - values are derived username from substitution operation 1456: applied to $uname. 1457: 1458: For example, in the msu domain the rule "msuemail" will replace an MSU 1459: email address submitted as a username, with the part before the @msu.edu, 1460: (known as the MSUNetID), which is what is used in LON-CAPA as a username. 1461: 1462: if ($dom eq 'msu') { 1463: foreach my $item (@{$to_check}) { 1464: if ($item eq 'msuemail') { 1465: if ($uname =~ /^(\w{2,8})\@msu\.edu$/) { 1466: $resultshash->{$item} = $1; 1467: } 1468: } 1469: } 1470: } 1471: 1472: returns 'ok' if no processing error. 1473: 1474: =cut 1475: 1476: sub unamemap_check { 1477: my ($dom,$uname,$to_check,$resultshash) = @_; 1478: my $outcome; 1479: return $outcome; 1480: } 1481: 1482: =pod 1483: 1484: =item AUTOLOAD() 1485: 1486: Incoming data: none 1487: Returns '' 1488: 1489: Prevents errors when undefined subroutines are called in this package 1490: Will allow new routines added in the future to be called from lond etc. 1491: without the need for customized versions of local*.pm packages to be 1492: modified to include the new subroutines immediately. 1493: 1494: See "Programming Perl" 3rd ed. pp 296-298. 1495: 1496: =back 1497: 1498: =cut 1499: 1500: sub AUTOLOAD { 1501: our $AUTOLOAD; 1502: return ''; 1503: } 1504: 1505: 1;