version 1.43, 2011/10/14 17:13:25
|
version 1.53, 2015/08/05 18:47:17
|
Line 123 sub run() {
|
Line 123 sub run() {
|
<middlename>D</middlename> |
<middlename>D</middlename> |
<startdate></startdate> |
<startdate></startdate> |
<studentID>A12345678</studentID> |
<studentID>A12345678</studentID> |
|
<credits></credits> |
|
<inststatus></inststatus> |
</student> |
</student> |
|
|
with the following at the top of the file |
with the following at the top of the file |
Line 147 sub run() {
|
Line 149 sub run() {
|
If dates are to included in the XML file, they should be in the format |
If dates are to included in the XML file, they should be in the format |
YYYY:MM:DD:HH:MM:SS (: separators required). |
YYYY:MM:DD:HH:MM:SS (: separators required). |
|
|
|
The <credits> tag need only be used if the credits earned by the students will |
|
be different from the default for the course. The course default is set when the |
|
course is created and can be modifed by a Domain Coordinator via "View or |
|
modify a course or community" on the DC's Main Menu screen. |
|
|
|
A value for <inststatus> should be the institutional status used for students, |
|
and should be one of the types defined in the "Institutional user types" |
|
section in the domain config screen for: |
|
"Default authentication/language/timezone/portal/types" |
|
|
|
If no status types are defined for the domain this tag can be omitted. |
|
If Autoupdate.pl is enabled in your domain, updates to the institutional |
|
status set here will be updated by Autoupdate.pl, should changes occur. |
|
|
If there were 10 students in fs03nop590001, 5 students in fs03nop59o601, |
If there were 10 students in fs03nop590001, 5 students in fs03nop59o601, |
8 students in fs03nop590602, and 2 students in fs03ost580002, |
8 students in fs03nop590602, and 2 students in fs03ost580002, |
then $$reply{'43551dedcd43febmsul1'} = 25 |
then $$reply{'43551dedcd43febmsul1'} = 25 |
Line 301 validate_instcode takes three arguments
|
Line 317 validate_instcode takes three arguments
|
(c) an optional institutional username for the course owner. |
(c) an optional institutional username for the course owner. |
|
|
An array is returned containing (a) the result of the check for a valid |
An array is returned containing (a) the result of the check for a valid |
instcode, and (b) an (optional) course description. |
instcode, (b) an (optional) course description, and (c) the default credits |
|
earned by students when completing this course. If no institutional credits |
|
value is available, the default credits for the course can be set via the |
|
course request form, or via XML in a batch file, of via the web form used |
|
by the Domain Coordinator to create new courses one at a time. |
|
|
A valid instcode is confirmed by returning 'valid'. |
A valid instcode is confirmed by returning 'valid'. |
|
|
If no course description is available, '' should be set as |
If no course description is available, '' should be set as |
the value of the second item in the returned array. |
the value of the second item in the returned array. |
|
|
Line 312 sub validate_instcode {
|
Line 334 sub validate_instcode {
|
my ($dom,$instcode,$owner) = @_; |
my ($dom,$instcode,$owner) = @_; |
my $outcome = ''; |
my $outcome = ''; |
my $description = ''; |
my $description = ''; |
return ($outcome,$description); |
my $credits = ''; |
|
return ($outcome,$description,$credits); |
} |
} |
|
|
=pod |
=pod |
Line 335 Other scenarios are possible, and the ro
|
Line 358 Other scenarios are possible, and the ro
|
to whatever rules a domain wishes to implement to run validations against |
to whatever rules a domain wishes to implement to run validations against |
given the data passed in to the routine. |
given the data passed in to the routine. |
|
|
validate_crsreq takes six arguments - |
validate_crsreq takes seven arguments - |
(a) the LON-CAPA domain that will contain the course. |
(a) the LON-CAPA domain that will contain the course. |
(b) the username:domain for the course owner. |
(b) the username:domain for the course owner. |
(c) the course type (official, unofficial or community) |
(c) the course type (official, unofficial or community) |
(d) a comma-separated list of institutional affiliations of |
(d) a comma-separated list of institutional affiliations of |
the course owner. |
the course owner. |
(e) the institutional code (in the MSU case this is a concatenation of |
(e) the institutional code (in the MSU case this is a concatenation of |
semester code, department code, and course number, e.g., fs03nop590. |
semester code, department code, and course number, e.g., fs03nop590). |
(f) a comma-separated list of institutional sections included in |
(f) a comma-separated list of institutional sections included in |
the course request (only applicable to official courses). |
the course request (only applicable to official courses). |
|
(g) an optional reference to a hash of custom form data. |
|
The custom form data will come from crsreq_updates(), with one |
|
additional item: $custominfo->{'_LC_clonefrom'}, provided internally |
|
(the courseID of the LON-CAPA course being cloned). |
|
|
A valid courserequest is confirmed by returning 'process'. |
A valid courserequest is confirmed by returning 'process'. |
The following can be returned: process, rejected, pending, approval or error (with error condition - no :), followed by a : and then an optional message. |
The following can be returned: process, rejected, pending, approval or |
|
error (with error condition - no :), followed by a : and then an optional message. |
|
|
(a) process - the requestor is the recorded instructor - create the course |
(a) process - the requestor is the recorded instructor - create the course |
|
|
(b) rejected - the requestor should never be requesting this course, reject the |
(b) rejected - the requestor should never be requesting this course, reject the |
request permanently |
request permanently |
|
|
(c) pending - the requestor is not the recorded instructor, but could |
(c) pending - the requestor is not the recorded instructor, but could |
become so after administrative action at the institution. Put the |
become so after administrative action at the institution. Put the |
request in a queue and check localenroll:validate_instcode() |
request in a queue and, if an official course, check |
periodically until the status changes to "valid". |
localenroll:validate_instcode() periodically until the status changes to |
|
"valid". |
|
|
(d) approval - the request will be held pending review by a Domain Coordinator. |
(d) approval - the request will be held pending review by a Domain Coordinator. |
|
|
(e) error (followed by the error condition). |
(e) error (followed by the error condition). |
|
|
=cut |
=cut |
|
|
sub validate_crsreq { |
sub validate_crsreq { |
my ($dom,$owner,$crstype,$inststatuslist,$instcode,$instseclist) = @_; |
my ($dom,$owner,$crstype,$inststatuslist,$instcode,$instseclist,$custominfo) = @_; |
my $outcome = 'approval'; |
my $outcome = 'approval'; |
return $outcome; |
return $outcome; |
} |
} |
Line 419 sub crsreq_checks {
|
Line 452 sub crsreq_checks {
|
|
|
=pod |
=pod |
|
|
|
=item crsreq_updates() |
|
|
|
This is used to customize the LON-CAPA course request process. |
|
There are two hash references: $incoming, and $outgoing; $incoming can |
|
contain additional information collected from the requester, whereas $outgoing |
|
can contain custom items to send back to lonrequestcourse.pm, which creates the |
|
HTML displayed to the user during a course request. |
|
|
|
Different key-value pairs may be returned to lonrequestcourse.pm in the $outgoing |
|
hashref depending on the current action. The available actions are: |
|
review, prevalidate, process, created and queued. |
|
|
|
One scenario would be to return HTML markup in: $outgoing->{'reviewweb'}, |
|
i.e., where the action is 'review', to prompt the user to provide additional |
|
information as part of the course request, at the request review stage, |
|
(i.e,, the page which contains the button used to submit a completed course request). |
|
|
|
The HTML could contain form elements (e.g., radio buttons etc.). The value(s) |
|
selected by the requester in those form elements will be available in the incoming |
|
hashref, for a subsequent action, if the corresponding keys have been included |
|
in $outgoing->{'formitems'}, i.e., $outgoing will be hash of a hash. If a |
|
particular form item will the single valued, the value set for the key in the |
|
inner hash in $outgoing should be 1, otherwise, if it will be multi-valued, |
|
the value should be multiple. |
|
|
|
The $outgoing hashref can contain a 'formitems' key for both the prevalidate |
|
and process actions, as calls to localenroll::crsreq_update() can originate |
|
in lonrequestcourse::process_request() for both of those actions. |
|
|
|
The retrieved form values are passed to localenroll::validate_crsreq() as the |
|
optional seventh arg (a hashref) -- $custominfo. |
|
|
|
=cut |
|
|
|
sub crsreq_updates { |
|
my ($cdom,$cnum,$crstype,$action,$ownername,$ownerdomain,$fullname,$title, |
|
$code,$accessstart,$accessend,$incoming,$outgoing) = @_; |
|
unless (ref($outgoing) eq 'HASH') { |
|
return 'fail'; |
|
} |
|
my %extrainfo; |
|
if (ref($incoming) eq 'HASH') { |
|
%extrainfo = %{$incoming}; |
|
} |
|
if ($action eq 'review') { |
|
$outgoing->{'reviewweb'} = ''; |
|
} elsif ($action eq 'prevalidate') { |
|
$outgoing->{'formitems'} = {}; # key=>value, where key is form element name |
|
# and value is multiple, if there |
|
# are multiple form elements with |
|
# the same name. |
|
} elsif ($action eq 'process') { |
|
$outgoing->{'formitems'} = {}; # key=>value, where key is form element name |
|
# and value is multiple, if there |
|
# are multiple form elements with |
|
# the same name. |
|
} elsif ($action eq 'created') { |
|
$outgoing->{'createdweb'} = ''; |
|
$outgoing->{'createdmsg'} = [{ |
|
mt => '', |
|
args => [], |
|
}]; |
|
$outgoing->{'createdactions'} = { |
|
environment => {}, |
|
}; |
|
# environment can contain key=>value for |
|
# items to set in the course environment. |
|
# These would be items which are NOT included |
|
# in the items set via options in the course |
|
# request form. Currently self-enrollment |
|
# settings are the only ones allowed, i.e., |
|
# internal.selfenroll_types internal.selfenroll_registered |
|
# internal.selfenroll_section internal.selfenroll_start_access |
|
# internal.selfenroll_end_access internal.selfenroll_limit |
|
# internal.selfenroll_cap internal.selfenroll_approval |
|
# internal.selfenroll_notifylist |
|
} elsif ($action eq 'queued') { |
|
$outgoing->{'queuedmsg'} = [{ |
|
mt => '', |
|
args => [], |
|
}]; |
|
$outgoing->{'queuedweb'} = ''; |
|
} |
|
return 'ok' |
|
} |
|
|
|
=pod |
|
|
=item create_password() |
=item create_password() |
|
|
This is called when the authentication method set for the automated |
This is called when the authentication method set for the automated |
Line 816 sub get_userinfo {
|
Line 937 sub get_userinfo {
|
|
|
=pod |
=pod |
|
|
|
=item get_multusersinfo |
|
|
|
(a) $dom - domain |
|
(b) $type - username or id |
|
(c) $unamenames - reference to hash containing usernames of users |
|
(d) $instusers - reference to hash which will contain info for user |
|
as key = value; keys will be one or all of: |
|
lastname,firstname,middlename,generation,id,inststatus - |
|
institutional status (e.g., faculty,staff,student) |
|
Values are all scalars except inststatus, |
|
which is an array. |
|
(e) $instids - reference to hash which will contain ID numbers - |
|
keys will be unique IDs (student or faculty/staff ID) |
|
values will be either: scalar (username) or an array |
|
if a single ID matches multiple usernames. |
|
|
|
returns 1 parameter - 'ok' if no processing error, or other value |
|
if an error occurred. |
|
|
|
side effects - populates the $instusers and $instids refs to hashes. |
|
with information for specified username, or specified |
|
id, if fifth argument provided, from all available, or |
|
specified (e.g., faculty only) institutional datafeeds, |
|
if sixth argument provided. |
|
|
|
WARNING: You need to set $outcome to 'ok' once you have customized |
|
this routine to communicate with an instititional |
|
directory data source, otherwise retrieval of institutional |
|
user information will always be reported as being unavailable |
|
in domain $dom. |
|
|
|
=cut |
|
|
|
sub get_multusersinfo { |
|
my ($dom,$type,$usernames,$instusers,$instids) = @_; |
|
my $outcome = 'unavailable'; |
|
return $outcome; |
|
} |
|
|
|
=pod |
|
|
=item inst_usertypes() |
=item inst_usertypes() |
|
|
|
Starting with LON-CAPA 2.11.0 use of this subroutine |
|
is deprecated. The domain configuration web GUI |
|
accessible to Domain Coordinators will be used to |
|
manage institutional types. If you have previously |
|
customized this routine, then values set there will |
|
be used when displaying the "Institutional user types" |
|
section in the domain config screen for: |
|
"Default authentication/language/timezone/portal/types". |
|
|
|
Once you have visited that screen and saved the settings, |
|
configuration thereafter will be via the web GUI of |
|
values stored in the domain's configuration.db file on |
|
the primary library server in the domain, and values in |
|
inst_usertypes() will no longer be consulted. |
|
|
Incoming data: three arguments |
Incoming data: three arguments |
(a) $dom - domain |
(a) $dom - domain |
(b) $usertypes - reference to hash which will contain |
(b) $usertypes - reference to hash which will contain |