From Samuli Karevaara (samuli.karevaara at lamk.fi) Thursday, 8 September 2005, 06:49 PM:
At least the bit
if(isset($USER->student) && is_array($USER->student)) {
$courses = $USER->student;
}
if(isset($USER->teacher) && is_array($USER->teacher)) {
$courses = $USER->teacher;
}
can't be right. For teachers all the courses that they are enrolled in as a student are overwritten with the $courses = $USER->teacher;
From Samuli Karevaara (samuli.karevaara at lamk.fi) Thursday, 8 September 2005, 06:54 PM:
Okay, more on this: changing the upper code to
if(isset($USER->teacher) && is_array($USER->teacher)) {
$courses = $USER->teacher + $courses;
}
fixes this for the initial visit on the front page, but visiting a course calendar sets the front page calendar to show the events for that visited single course also.
From Jon Papaioannou (pj at moodle.org) Friday, 9 September 2005, 12:56 AM:
Thanks for digging into this Samuli!
I 'll take a look as soon as I get the chance to see what exactly is going on. Keep writing here if there's anything else of interest you find out.
Also, I apologize for the voodoo which is going on with the $SESSION variables and such, but it was either this or hardcoding calendar-related information in all URLs throughout Moodle. I hope you agree that it was the lesser evil. 
[Considering that when developing the calendar I didn't even have CVS access, it was not even a choice really]
From Samuli Karevaara (samuli.karevaara at lamk.fi) Friday, 9 September 2005, 01:29 PM:
I understand that solutions like this are sometimes/often necessary to get anything done, instead of half-done non-working clean beginnings (like most of my projects ). I hope I didn't sound harsh, just a bit frustrated... Also, coding around other peoples code is tricky enough.
On my wish list: classes for User, Course and so on, with precise-info-loading capabilities, methods like fetch just the course names + id's to produce course listings (instead of loading everything to $courses to print just the titles) and so on. I know they are on your wish list too
The user belongs to these courses would be a nice method, for example Static methods, lazy loading tricks and session caching could be used to make these more efficient than the current everything you need is here, just dig deeper
(Okay, running out of smileys here...)
From Samuli Karevaara (samuli.karevaara at lamk.fi) Wednesday, 12 October 2005, 10:17 PM:
What's going on here is: calendar/view.php checks if it has to switch to show another courses events by reading optional_variable($_GET['course'], 0);
(one nono in my mind is that this writes back to $_GET, that is, the query string...)
First issue that arises is that the site front page calendar block doesn't provide the course number (SITEID in this case) if you click the month name to get to the calendar view. Thus, you end up looking at the events for the last course that you viewed the calendar for, even though you're coming from SITEID.
Secondly, the front page block still wouldn't show the events for all of the users courses, as it has no such course switch check, just the calendar/view.php.
IMHO the front page calendar should always show events for all of the users courses, as it has no visual clue to tell you which course it's showing the events for.
I did a temporary ugly hack (you see, I complain about this to others but still do it my self, the way of the world i Guess :_) ) and added following lines to be called somewhere from the /index.php:
$SESSION->cal_courses_shown = calendar_get_default_courses(true);
$SESSION->cal_course_referer = intval(SITEID);
More things, really overloading this bug comment thread, a nono also:
- Isn't there another (maybe still not an elegant, but more consistent) way to check what course are we sitting on at? (the course global hack?)
- Is there a reason to use a home cooked session object $SESSION instead of the built-in $_SESSION one?
Bug
Closed
Major
From Samuli Karevaara (samuli.karevaara at lamk.fi) Thursday, 8 September 2005, 06:49 PM:
At least the bit
if(isset($USER->student) && is_array($USER->student)) { $courses = $USER->student; }
if(isset($USER->teacher) && is_array($USER->teacher)) { $courses = $USER->teacher; }
can't be right. For teachers all the courses that they are enrolled in as a student are overwritten with the $courses = $USER->teacher;
From Samuli Karevaara (samuli.karevaara at lamk.fi) Thursday, 8 September 2005, 06:54 PM:
Okay, more on this: changing the upper code to
if(isset($USER->teacher) && is_array($USER->teacher)) { $courses = $USER->teacher + $courses; }
fixes this for the initial visit on the front page, but visiting a course calendar sets the front page calendar to show the events for that visited single course also.
From Jon Papaioannou (pj at moodle.org) Friday, 9 September 2005, 12:56 AM:
Thanks for digging into this Samuli!
I 'll take a look as soon as I get the chance to see what exactly is going on. Keep writing here if there's anything else of interest you find out.
Also, I apologize for the voodoo which is going on with the $SESSION variables and such, but it was either this or hardcoding calendar-related information in all URLs throughout Moodle. I hope you agree that it was the lesser evil.
[Considering that when developing the calendar I didn't even have CVS access, it was not even a choice really]
From Samuli Karevaara (samuli.karevaara at lamk.fi) Friday, 9 September 2005, 01:29 PM:
I understand that solutions like this are sometimes/often necessary to get anything done, instead of half-done non-working clean beginnings (like most of my projects
). I hope I didn't sound harsh, just a bit frustrated... Also, coding around other peoples code is tricky enough.
On my wish list: classes for User, Course and so on, with precise-info-loading capabilities, methods like fetch just the course names + id's to produce course listings (instead of loading everything to $courses to print just the titles) and so on. I know they are on your wish list too
The user belongs to these courses would be a nice method, for example
Static methods, lazy loading tricks and session caching could be used to make these more efficient than the current everything you need is here, just dig deeper 
(Okay, running out of smileys here...)
From Samuli Karevaara (samuli.karevaara at lamk.fi) Wednesday, 12 October 2005, 10:17 PM:
What's going on here is: calendar/view.php checks if it has to switch to show another courses events by reading optional_variable($_GET['course'], 0);
(one nono in my mind is that this writes back to $_GET, that is, the query string...)
First issue that arises is that the site front page calendar block doesn't provide the course number (SITEID in this case) if you click the month name to get to the calendar view. Thus, you end up looking at the events for the last course that you viewed the calendar for, even though you're coming from SITEID.
Secondly, the front page block still wouldn't show the events for all of the users courses, as it has no such course switch check, just the calendar/view.php.
IMHO the front page calendar should always show events for all of the users courses, as it has no visual clue to tell you which course it's showing the events for.
I did a temporary ugly hack (you see, I complain about this to others but still do it my self, the way of the world i Guess :_) ) and added following lines to be called somewhere from the /index.php:
$SESSION->cal_courses_shown = calendar_get_default_courses(true);
$SESSION->cal_course_referer = intval(SITEID);
More things, really overloading this bug comment thread, a nono also: