With 2500 courses the calendar was causing around 15000 queries at login and 5000 on the home page.
- Replaced queries inside loops with single unlooped queries.
- Fixed calendar so that course events will show when the users role is assigned at a category level.
- Moved calendar_session_vars() function call out of calendar/lib.php (including a lib should not have side effects)
Author: Matt Clarkson - with some conflict resolution from MartinL
is not pre-filled in the forms. This is a regression, no idea how and when
it happened. Investigating...
First of all let's get rid of this "HACK! Don't use!" function...
When adding recurring events, if the event title contained an apostrophe
then only the first event of the series would get created. Tricky bad
interaction with add_to_log, the reporter for this should get a prize. ;-)
Fix for bug 3364:
The Great Global $course Hack strikes again. I had to put in another instance
of the hack for course themes to work in the "calendar" part of the course.
Hopefully some day we 'll do all that "correctly"! (search for "hack" in
weblib and despair).
More correct handling of group events, we cannot simply omit them because
the course has "no groups" UNLESS groupmodeforce == 1 as well.
Sadly, this severely weakens the performace optimizations :(
See bug 3303 for an example of what the problem was before.
Creating course and group events now requires the same privileges as posting
in a forum. For course events (including site course, i.e. site events), any
teacher can create one.
For group events, the teacher must either have editing rights in the course
or be a member of the group the event is for.
These are the changes from MOODLE_13_STABLE, merged into trunk
The tag MOODLE_13_MERGED on the MOODLE_13_STABLE branch now refers to this point
The biggest changes here are the fixes for HTML editor in all standard modules
