From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 02:27 AM:
Thanks Bruno, I will commit your changes.
Unfortunately this won't fix the problem that a user's activity on the site front page will be ignored. The only way that could be fixed would be to introduce an extra field 'timeaccess' in the user table that would get updated by activity on the front page in the same way that the 'timeaccess' field in the user_students and user_teachers are updated by activity in courses.
Martin, do you think that should be done?
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 03:59 AM:
could we use course id 1 for tracking timeaccess on the main page?
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 04:04 AM:
No, we can't, because there are no entries in user_students for courseid = 1.
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 04:17 AM:
it is not being done now... but is that the easiest solution to this problem: to automatically create an entry in user_students for all users with course_id 1 and then to automatically update that every time they load the frontpage?
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 04:20 AM:
even easier: to just cause an update to lastaccess in users when frontpage is accessed. The field lastaccess should store the lastaccess time for ANY moodle page ... would that solve the problem?
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 04:31 AM:
Your first solution would be the easiest solution but not necessarily the most efficient, see http://moodle.org/mod/forum/discuss.php?d=8452#45836.
Your second solution won't work because the lastaccess field is already used otherwise, namely to enable the recent activity block to show all activities since the last access.
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 05:47 AM:
wow, you have already thoroughly discussed this problem!
what is not clear to me is the inefficiency... all I see is that the user_students table will be increased by n records where n= the number of records in users ...does not sound inefficient to me!
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 03:29 PM:
I agree with your assessment. In general, assuming that every student is enrolled on average in 4 courses it would increase the length of the user_students table by 25%. Not sooo much.
However: just for the improvement in the online user feature it may still be too big a price to pay (always thinking of a university with 20,000 students).
The same improvement in the online user feature could be achieved with an extra field in the user table. So I think if anything, we should implement the extra field in the user table.
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 03:59 PM:
FWIW, I am fine with adding a companion to timeaccess in table users... unless we can predict future uses (besides keeping track of last access time) for automatically registering all users in user_students course 1.
off the top of my head, I think I read that someone wanted to have markable activities in course 1 ... would that not require registration ... come to think of it, if such things occur, they need not be mandatory but only those who would be marked would have an entry in user_students.
From Bruno Vernier (vernier at vc.bc.ca) Sunday, 29 August 2004, 04:05 PM:
the more I show v1.4beta to other teachers, the more I am dealing with the following confusion: they think of the frontpage as a complete course in itself and keep expecting to see all the features of the other (real) courses ...
my gut feeling is that we should keep the programming algorithms for pseudo-meta course 1 as similar as possible to the other courses because I doubt this confusion is about to go away soon.
From Martin Dougiamas (martin at moodle.com) Sunday, 29 August 2004, 04:32 PM:
I don't agree with updating the user table AS WELL as the user_students table on every access.
I'm cautiously OK with enrolling everyone in the site course, but we need to think through all the implications. People need to be able to unenrol themselves, for example, so what does that mean for users still browsing the site pages but unenrolled?
Also, do we want to ENCOURAGE the wrong perception that Bruno mentioned (why do you think it is happening, bruno? teachers don't normally have admin accounts?)... perhaps we should make the front page even LESS course-like.
Something for cooking in the backburner ...
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 04:41 PM:
First of all: I think we should avoid the impression that the site front page is just another course. I must say that I have never had that phenomenon here at York that teachers thought of the site front page as another course.
If we do think it is important that the online users block on the site page correctly shows also those users engaged in activities on the site page only then my proposal was to update a 'timeaccess' field in the user table only when a front page activity adds to the logs. It is not a matter of writing to the user table and the user_students table, it is either or, depending on whether the acitivty is in a course or on the site.
Bruno mentions markable activities on the site page. They are allowed already (even though I think they are a bad idea) and they do not need entries in the user_students table.
From Martin Dougiamas (martin at moodle.com) Sunday, 29 August 2004, 05:16 PM:
My misunderstanding, sorry, I didn't quite read you right.
But Bruno is right about lastaccess ... I think we can just use the lastaccess field - I don't think it's used anywhere anymore.
If you have time a quick grep around should confirm this.
That used to be the field updated by add_to_log all the time, however, then I moved this to course-based, so the timeaccess fields were added. That's why many ofthe datalib functions return timeaccess as lastaccess, it's for backward compatibility.
Anyhow, if this field isn't being used anywhere (as I suspect) then we could just add a few lines to add_to_log() so that user.lastaccess is updated whenever the user_xxxxxx tables aren't.
How does that sound?
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 05:49 PM:
You appear to be right, the lastaccess field should simply play the same role as the timeaccess field for the courses, i.e., it should be updated on each logged activity. I'll do it.
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 06:04 PM:
It is a bit weird at the moment:
1) 'lastaccess' IS updated whenenver require_login() is used from within a course but not when it is used from the site page.
I'll fix that so that it is always updated.
2) 'timeaccess' is updated whenever add_to_log is called.
This means that on many pages both the user table and the user_student table are updated. I think some rationalisation would be in order: how about updating only either 'timeaccess' or 'lastaccess', depending on whether we are in a course or on the site? And how about always doing this in require_login rather than add_to_log?
From Gustav Delius (gwd2 at york.ac.uk) Sunday, 29 August 2004, 07:37 PM:
O.k., for moodle 1.4 I have made the minimal change which was to update the lastaccess field when add_to_log is called from the site. The online user feature now works fine. However for moodle 1.5 I think things should be rationalised. I will open a new bug for that.