Last night I had a long and helpful discussion with with Mark Nelson about MDL-40063 (implementing the log API in the quiz) during which I learned a lot more about the log API than I previously knew.
In trying to work out the best way to do certain things, we came across a problem that has not been addressed yet, but I fear it is going to cause problems in Moodle 2.8.
The problem has not arisen yet because in Moodle 2.7, the scope was restricted to only cover converting existing add_to_log calls to the new API. There has not yet been an attempt to add in missing logging.
Another contributory factor to the problem is that, in the new log/events API, the recommendation is to raise the event relevant library function where the change is implemented, whereas in the past the rue was to log things in the outer-most UI layer. To give a specific example, in the past mod_quiz\delete_attempt used to be logged in the report class report.php, but now it should be logged in quiz_delete_attempt in locallib.php. There are many ways in which this is a good change. For example, it means that a quiz attempt being deleted is always logged in the same way. There are two ways in which it is bad:
- It can be bad for performance. It leasts easily to n+1 DB query performance problems.
- The point of logging is learning analytics. It is not necessarily enough to know that an attempt was deleted. You need to know who deleted it, and possibly you want some other context that might let you deduce why they deleted it.
This problem of context becomes more acute when you start thinking of core subsystems. The specific example we were grappling with was question_manually_graded. This processing happens in the question system, and following the design principles of the new log API, the event should be raised at the lowest level, which question_behaviour::process_comment. However, questions work the same wherever they are used, and the question API is well designed so extraneous information is not passed around. Hence, the necessary information to raise a semantically rich event is not available there.
When we spotted this problem, Mark and I went looking for other places where this problem might have arisen and been solved. The ideas that immediately came to mind were:
- Ratings (e.g. you can rate this forum post)
- Comment API
- Question (we ought to be logging more interesting stuff that just teachers manually grading).
When we went to look, we found no add_to_log calls in either ratings or comments, and so no attempt has been made to solve these issues in 2.7.
I think it is clear that these are all educationally interesting events that you might want to log for learning analytics, so we will have to solve this problem of educationally interesting events that are both generic (provided by a core API) but also where context matters, and so we need to include it in the event.
One option is to change all the APIs just to pass in the extra information required to trigger the events. However, that seems like a bad design. The tail wagging the dog.
So, suggestions welcome.