version 1.43, 2011/10/14 17:13:25
|
version 1.51, 2015/05/30 16:14:38
|
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(). |
|
|
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 417 sub crsreq_checks {
|
Line 444 sub crsreq_checks {
|
return 'ok'; |
return 'ok'; |
} |
} |
|
|
|
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 |
=pod |
|
|
=item create_password() |
=item create_password() |
Line 818 sub get_userinfo {
|
Line 897 sub get_userinfo {
|
|
|
=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 |