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.
The new constant is PAGE_COURSE_VIEW, and it's more streamlined with the
new CSS-related ids for 1.5. There are great possibilities for the future
here, so we 're getting ready.
On the other hand, this has to be the ugliest hack I 've ever inflicted
on any program (look at pagelib.php). Thankfully it will only stay for just
a little while.
* Configurable defaults for the calendar upcoming events lookahead and
maximum upcoming events displayed (bug #1623)
* Configurable setting for which days of the week are treated as weekend
(bug #1919)
* Configurable setting for which day starts the week (the admin can now set
this as the default for new users and guests without messing with language
packs) (no butracker issue)
Includes preliminary support for DST!
Includes "admin sees all events or only own?" setting (bug 1972)
WARNING: Modified moodlelib.php to explicitly specify NOT-DST when
calling mktime() and gmmktime(). This is essential since we don't want
PHP to second-guess us for the DST matters, but... it may affect existing
code?
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
I hope this time I got everything changed to the new Page interface! I 'm
really sorry for messing up and breaking new installations... :(
Also moved the only two functions of the API outside the page_base class.
Student and teacher enrolments now unique + version bump
Made student and teacher enrolments unique, enforced at the database level. This patch also removes a cleanup job in moodle's cron that removed duplicate enrolments.
Merge of patchset arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-422
--------------
Brand-new pagelib.php at your disposal! It slices, it dices, it makes your coffee.
It still doesn't understand women... Read the comments in pagelib.php for a first
impression. Feedback highly encouraged!
Blocks code has undergone significant changes to work with Pages. Flexibility is its
middle name, since I think (without having tried it) that adding e.g. a third
placeholder for "center" blocks in courses, with full support for moving around etc,
will now take about 15 lines of new or edited code. If you are not impressed yet, I
suggest watching a documentary on solar physics. :P
MINOR CHANGES:
--------------
Added instance_allow_config() in the blocks class hierarchy to supplement per-instance
configuration options. You can override it to return true and thus get configuration
amenities without allowing multiple instances.
Minor polishing to comments and documentation (whatever caught my eye was game).
Tightened up some code here and there by utilizing all the new features.
BUGFIXES:
---------
A bug in restore_execute.html caused hidden blocks to not be restored at all.
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.
