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.
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.
options or not. This is handled as in the resource module. The
"Show advanced options" button is only shown if the admin has
chosen to declare some of the options as advanced.
There are now 4 review options as suggested by Martin in
http://moodle.org/mod/forum/discuss.php?d=16709
Provides separate buttons "Update this quiz" and "Edit questions",
see http://moodle.org/mod/forum/discuss.php?d=16708. To make this
possible edit.php can now be called with a quiz id and it saves
its data itself rather than relying on mod.php.
mod.html now has a "Save changes" and a "Save changes and edit questions" button.
"Attempt quiz now" button gets a different language string for
re-attempts. This is currently set to "Re-attempt quiz".
After viewing the feedback for an attempt the "Continue" button
leads back to the course homepage, as requested in bugs 1224 and
1976. If there is no feedback the user is brought straight to quiz/view.php.
well with debug = on. In fact the change password screen didn't play at all.
Made a few small changes to fix notices and now everything works OK.
Added a missing language string.
*****************
This problem may very well exist in MOODLE_14_STABLE too! Unfortunately I
don't have access to a 1.4 checkout right now, so it will have to wait.
*****************
If the admin specifies a Policy Agreement (via URL in the config variables)
then each user is required to see and agree to that document once before
continuing.
To get everyone to see it again (on an update, say) one just needs to issue:
UPDATE user SET policyagreed = 0
Backward compatibility is maintained, i.e. you can restore ANY version
backups without problems in 1.5. When "adding backup data to an existing
course", no blocks are added. I 'm not sure what the correct behavior
would be in this case.
When restoring a backup from Moodle <= 1.2, the new course SHOULD be given
default blocks when it is restored. I have not actually tested this, my
tests were with version 1.3 and 1.4 backup format.
Code based on the work of Daryl Hawes for the blog module. Thanks, Daryl!
Please test the hell out of it as it's sure to have issues that need to be
ironed out.
