The visibility of coursemodules is now always set through the function set_coursemodule_visible() in order to make sure that the associated events get updated in the calendar appropriately.
If moving a coursemodule to a hidden section then the module is set to hidden as well and its events are hidden in the calendar.
If deleting a coursemodule its events are deleted from the calendar.
The function choose_from_menu() has an extra optional argument $disabled which, when set to true, will disable the menu.
For the sake of consistency the function set_groupmode_for_module has been renamed to set_coursemodule_groupmode and the functions show_course_module() and hide_course_module() have been combined to set_coursemodule_visible().
Added $user->theme and $course->theme choices, controlled by admin
variables on the main config variables page.
By default this is all turned off, since multiple themes can be
a little disorienting.
A hidden feature is session themes ... you can change the theme
on any page by passing theme=xxxx as a parameter. By default this
requires sesskey (so that people don't change theme on each other),
but this security can be switched off using a hidden variable
$CFG->allowthemechangeonurl = true; Good for quick tests.
Admin can put a site on hold during an upgrade or theme changing etc
Controlled by a file in dataroot, so it can also be controlled via command line:
touch moodledata/1/maintenance.html
rm moodledata/1/maintenance.html
This patch contains:
* email_to_user will set the envelope sender to a special bounce processing address (based on $CFG settings)
* email_to_user will accept (and set) a reply-to header, to be generated by the module calling the function.
* new functions:
* generate_email_processing_address - ALWAYS use this to generate the reply-to header. reply-to header will look like this:
(LIMIT: 64 chars total)
prefix - EXACTLY four chars
encodeded, packed, moduleid (0 for core) (2 chars)
up to 42 chars for the modules to put anything they want it (can contain userid (or, eg for forum, postids to reply to), or anything really. 42 chars is ABSOLUTE LIMIT)
16 char hash (half an md5) of the first part of the address, together with a site "secret"
* moodle_process_email - any non-module email processing goes here (currently used for processing bounces)
* bounce handling:
* config settings for bounce threshold and ratio (and whether to handle bounces at all)
* if too many bounces occur against any given user, user_not_fully_set_up will force an email address change
* associated functions (over_bounce_threshold, set_send_count, set_bounce_count)
* handling emails to noreply address (see below)
* new script - admin/process_email.php
This script needs to be called from your mail program for anything starting with the 4 char prefix described above (and optionally, the noreply address)
It will bounce emails to the noreplyaddress, with a friendly "this is not a real email address" message
It will break down and unencode the email address into moduleid and validate the half md5 hash, and call $modname_process_email (if it exists). Arguments to these functions are: $modargs (any part of the email address that isn't the prefix, modid or the hash) and the contents of the email (read from STDIN).
* associated string changes/additions
* changes in config-dist.php to give clues as to how to set this up.
MODULE WRITERS!
take a look at new functions moodle_process_email and generate_email_processing_address in moodlelib.php for ideas about how to
* encode and unencode the arguments your module needs to do the processing
* how to deal with multiple "actions" for any given module.
Martin Langhoff <martin@catalyst.net.nz> will be writing up some PROPER documentation, containing amongst other things config settings for different mail servers (this was developed against Postfix). Feel free to email me with any feedback on the code or design, penny@catalyst.net.nz. Or post on the developer fourm.
