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.
Fixes to fix_course_sortorder() and course/category.php pages. (martinlanghoff)
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-160
Minor fix: moodle would crash on high number of courses when doing course creation -- should be more scalable now
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-164
Fix a bug I have introduced in fix_course_sortorder() - v2
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-210
Fixed nested transaction in fix_course_sortorder()
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-215
Performance and memory usage fixes for re-sort courses function
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-268
Major performance and correctness improvements in the functions that move courses up and down, reorder by name, and in fix_course_sortorder(). All now assume course-sortorder is unique (this is enforced at the DB)
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-332
fix_coursesortorder() bugfixes and logic simplification
arch-eduforge@catalyst.net.nz--2004/moodle--eduforge--1.3.3--patch-333
courses listing enhancements: bugfix on re-ordering, keep the right page on actions
All the page headers work correctly also on the site course.
On the site page the modules don't require login unless necessary or required by $CFG->forcelogin.
1) get_course_students, get_course_users and count_course_students when called with course=site will now use get_site_users instead of get_users. This I believe was the consensus reached in the discussions of how front-page activities should behave.
2) all functions can handle a list of exceptions now.
3) get_site_users now returns users in the order admins, teachers, students. Similarly for get_course_users. This makes the sorting bug 1727 a bit more bearable
4) new function search_users
The whole thing is really a mess because each function has slightly different conventions for its arguments. But the beta is too close to tidy this up now.
