Another problem is that final grade values are calculated only when you actually need them, which means the external system would not be notified immediately.

I am afraid that triggering events separately for each grade might multiply the number of sql queries thus making grader report operations even slower.

I see you marked fix version 1.9.6, why? Are you going to work on this? Did anybody promise this feature to you?

I guess I'll just go ahead and make another customisation. If you are unwilling to support people making local customisations in 1.9 please at least fix it in 2.0. Moodle used to be really good at having core open to hooks for people doing slightly special things.

I have to say, I'm still kind of of the opinion that

• The event TYPE should be responsible for knowing whether it should be processed at cron or immediately, not the handlers (or at least can force cron handling)

• calling events_trigger should 95% of cases do nothing more than insert_record('event', (object)array($eventtype, serialise($eventdata));

Events should be thrown indiscriminately and caught conservatively, just like exceptions.

I understand that partners and admins work mostly with stable branch and development in HEAD is not interesting for them and that is why the submit feature requests for already stable branches. If we want to make Moodle more reliable and stable should do this in HEAD only. This is a perfect example, this should have been already done in 1.9dev, not 1.9.6 - this feature may seem trivial, but in the end it might require weeks for implementation+testing, on the other hand if we do it in HEAD only it will be a few days of work and the testing would be done together with other changes later, there would be also 0% risk of regressions in stable branch. Once it lands in HEAD it would be much easier for you to backport it to 1.9x for your customers without the risk of unexpected changes in HEAD.