Moodle

I have the same issue. A friend of mine (PHP expert but not a Moodle user) had a look at it and came up with a theory. Here's a copy/paste of the info I posted in the moodle forum

Ok, here I am with, I hope, some clues as to where the problem may be situated. A friend of mine who is pretty good at PHP (but who doesn't use Moodle) had a quick look at the query and came up with the following suggestion (I am no techie, so I'll try and be as clear as I can)

What follows will be understandable to our developers, I hope..

My friend thinks the query gets too much info. If I'm not mistaken, normally the query for participation report says that if it can't find any logs of the student in the context of the activity, it will return NULL:true the line is:

AND
(l.id IS NULL

However, it seems to take into account actions that are situated outside the course, like just logging in to the Moodle site, so the NULL value is never true, so it can't display the "no" students.

I tested his hypothesis this way:
On my test platform, I created 4 students and did the following things:

• Student01: logged in to the course and did the activity
• Student02: logged in to the course but didn't do the activity
• Student03: was added manually to the students of the course, logged in on the platform but not to the course.
• Student04: was added manually to the platform but never logged in at all.

When I do a "participation report", this is what I get:
2 student
Student 04: No (never logged in to the platform)
Student 01: Yes (1) (logged in and did the activity)

My conclusion would be that the query seems to consider that just logging in to the platform is logged, obviously, but the query doesn't return NULL:True as it seems to take into account the student's logging in on the Moodle site. On the other hand, it can't display the others (Student02 and 03) as "Yes" as they haven't done the activity. As the query can't display them as "Yes" but can't display them as "no" (as the result is not NULL:true) it just ignores them...

I hope I was clear enough in the explanation... My friend doesn't really have the time to look into the problem further, and I'm only starting to understand php...
I'd be happy to provide more info or clear things up, if I can...

JL Delghust

Right in the middle of the academic year our university upgraded from moodle 1.8.7 to 1.9.4.

Much to my disappointment the bug reported in this MDL-16852 report has still not been fixed!

Whatever activity a participation report is required for, the only list of students displayed is that of students having taken part. Those students who have NOT taken part are NOT LISTED at all.

This is really bad, because I regularly use the participation report to send out messages to those students who have not taken part, and now I cannot see them listed.

Oh, and I can confirm the scenario described by Jean-Luc (the scenario of the 4 students). I have been able to reproduce it exactly on my 1.9.4 local installation.

There is obviously something wrong in the sql request in course/report/participation/index.php.
Looking forward for a fix, for me this is really a blocker in my daily use of moodle.

Joseph

Sorry to insist but this bug is a real blocker for my day-to-day use of moodle. Can someone please come up with a quick fix?

The sql query in moodle 1.8 was much more complicated but it worked fine. Here is an example:

SELECT DISTINCT prs.userid, u.firstname,u.lastname,u.idnumber,count(l.action) as count FROM (SELECT ra.userid, ra.roleid AS primary_roleid, ra.contextid, r.sortorder, r.name, r.description, r.shortname, c.instanceid AS courseid, c.contextlevel FROM mdl_role_assignments ra INNER JOIN mdl_role r ON ra.roleid = r.id INNER JOIN mdl_context c ON ra.contextid = c.id WHERE NOT EXISTS ( SELECT 1 FROM mdl_role_assignments i_ra INNER JOIN mdl_role i_r ON i_ra.roleid = i_r.id WHERE ra.userid = i_ra.userid AND ra.contextid = i_ra.contextid AND i_r.sortorder < r.sortorder ) ) prs JOIN mdl_user u ON u.id = prs.userid LEFT JOIN mdl_log l ON prs.userid = l.userid AND prs.courseid = l.course AND l.time > 0 AND l.course = 2 AND l.module = 'quiz' AND l.cmid = 27 AND action IN ('view','view all','report','attempt','editquestions','review','submit' ) WHERE prs.courseid = 2 AND prs.primary_roleid = 5 AND prs.contextlevel = 50 AND prs.courseid = 2 GROUP BY prs.userid,u.firstname,u.lastname,u.idnumber,l.userid ORDER BY lastname ASC

The sql query in moodle 1.9 is much shorter but does not work satisfactorily; e.g.:

SELECT ra.userid, u.firstname, u.lastname, u.idnumber, COUNT(l.action) AS count FROM mdl_role_assignments ra JOIN mdl_user u ON u.id = ra.userid LEFT OUTER JOIN mdl_log l ON l.userid = ra.userid WHERE ra.contextid IN (10,3,1) AND ra.roleid = 5 AND (l.id IS NULL OR (l.cmid = 27 AND l.time > 0 AND l.action IN ('view','view all','report','attempt','editquestions','review','submit' )) ) AND prs.courseid = 2 GROUP BY ra.userid, u.firstname, u.lastname, u.idnumber ORDER BY lastname ASC

Waiting eagerly for the solution,
Joseph

BUMP!
Further to my previous comment, pending a correct fix to this bug, can moodle core developers advise me on the feasibility of replacing the buggy request in moodle 1.9 with the lengty but working request in 1.8? This would have to go on our university production server and obviously our admin will be reluctant to hack something which might ruin our moodle platform (or slow it down considerably).
Joseph

Joseph, have you tried using CVS history to find out when this changed. That would tell you why and the associated bug number.

http://cvs.moodle.org/moodle/course/report/participation/index.php?r1=1.20.2.1&r2=1.20.2.2&pathrev=MOODLE_19_STABLE

So it is MDL-13549. Sadly that bug is a large vague change, so not much help there, but at least you now know who to talk to.

I am working on a large patch that should solve this also - provided we agree it is the right way for 2.0, unfortunately it will not be backprotable to 1.9.x

But Petr, this is a regression introduced by your last big change to the participants report. Surely it should be fixed.

Hi Tim and Petr,
I do hope we are on the right track now and some fix will be provided for moodle 1.9 ASAP (I really need this to work NOW and can't wait for 2..0). As Tim says it is definitely a regression.
TIA
Joseph

Hi all,

thanks for having a look at this, we'd really need this fix too..
TIA

JL

Tim: it should be fixed now, I just hoped somebody else will spend time on this and fix my sloppy left join

Jean: your steps helped me to reproduce this problem, after that fix was just a matter of seconds, thanks a lot for the report and all information

Joseph: all those ASAP, NOW, really bad, not satisfactory, etc. strong words will not help you much I guess because I tend to ignore all comments or posts with capitalised words in them unless those are PHP constants

Hi Petr,

MANY THANKS for fixing this bug. Just tested the fix, it works fine. I AM SORRY about all those strong words which echoed my frustration with this bug, especially at a time of stress here (our campus has been physically blockaded for about 4 weeks now and our moodle site has become my only contact with the students). I promise I will banish those rude ASAP, NOW, etc. words from my comments in the tracker and restrict capitals to "PHP constants" such as THANKS, etc.

Joseph

Joseph, thanks a lot for the testing! :-D

Petr, many thanks for the fix! I'll ask our admin to update our site and let you know, this is going to be much appreciated by our staff.
(I'm steadily turning into a moodle fanboy :-D )

stupid question maybe, but how could I get the fix? ^_'

Option 1: Upgrade to the latest 1.9.4+ weekly build on or after next Wednesday.

Option 2: Click the 'Version control' tab above, then in the Petr ?koda committed 1 file to 'Moodle CVS' on branch 'MOODLE_19_STABLE' section, click on the (+5 -11 lines) link to see exactly what was changed to fix this bug.

Again, thanks for the quick response!

Hi Jerome,
I don't quite see the point of adding a QA Assignee on a bug which has been resolved. Any reason?
Joseph

It is standard practice: http://docs.moodle.org/en/Tracker#Testing_issues

Oops! Thanks for clarifying, Tim!

Hi Joseph, as Tim said Weekly QA is for retesting fixed bug. I think I reopen at least 1 issue on 15 so it's quite useful.
Otherwise I confirm this issue works on 1.9. Students with no actions are shown.
Thanks everybody for your participation.