The old code assumed that the courseid would always be set but that is only the case for course events, not for user or group events. (See http://moodle.org/mod/forum/discuss.php?d=4466#20827 for a discussion about the meaning of the courseid field in the event table)
I also made the $courseid argument to get_coursemodule_from_instance() optional. It is not needed and in some cases it will not be know, as for example for non-course events created by activity modules.
Fixed upgrade bug that could show up in cases where:
- installations with large numbers of courses in a category AND 'hidden' courses in those categories
- where the database upgrade was performed while NOT in a logged-in-admin session
fix_course_sortorder() would fail to guarantee the uniqueness of course,sortorder and the new unique index on that column would fail to be created.
Sigh.
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.
Fixed an issue with postgres database upgrade code -- drop either index or constraint if they exist
Merge of patchset arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-430
Additional fixes for indexes in postgres. A few unique indexes may have been created non-unique. Still deferring the version bump -- please review the patch!
Merge of patchsets
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-423
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-425
raise_memory() now uses get_real_size(), duplicate function return_bytes() removed.
Issue discussed in 2202 (http://moodle.org/bugs/bug.php?op=show&bugid=2202).
Also seen as arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-424
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
rest of Moodle. The convention for blocks is now:
class block_something extends block_base { ... }
HOWTO updated accordingly, plus some more minor polishing. More to come.
Bugfix - value truncation to fit Moodle database
- Added truncate_userinfo() to cleanup data coming from external auth
- Fixed auth_user_create() to truncate user info as appropriate
Auth_ldap_user_sync
- created external script that calls the function
- much faster update strategy on postgres and mysql: auth_sync_users now to uses bulk inserts into a temp table, and then use LEFT JOINs and plain old SELECTs to determine what users it has to insert.
- we now loop over smaller sets of data -- we are still memory-bound, but (a) it'll be easy to use LIMIT to manage that and (b) memory use is much lower now in all cases.
- postgres: phased commits in auth_user_sync() for the batch user upload phase
- Several feature and performance enhancements:
- if a value is removed from ldap, it will be cleared from moodle
- no-op updates (where the data does not change) are skipped
- if a user disappears and then reappears in LDAP in two separate calls to auth_user_sync(),the account will be marked deleted and then be revived. before, the account would have been deleted and created anew.
Multi-source ldap values:
The LDAP auth module now accepts a comma separated set of LDAP field names. When creating or updating a user record, auth/ldap will retrieve all the relevant fields. The right-most values overwrites all the others.
This is particularly useful when updating the user's email address from an LDAP source, which may contain the email address in one of several fields (traditionally: mail, mailForwardingAddress, mailAlternateAddress).
If a value is updated and is set to update external auth and this field is using this multi-source ldap configuration, the auth/ldap module will retrieve the old value, find which field it was sourced from, and update that field in LDAP. If it fails to find the original source of the value, it will log it in error_log.
Log of patchsets applied:
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-131
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-137
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-139
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-172
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-173
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-189
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-190
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-208
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-212
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-216
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-279
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-282
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-287
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-294
