Moodle

Adding some events_trigger() calls to these look like a good idea.

Yes I totaly agree with that. I just wrote most of the calls needed into my code for testing our module - and it all works pretty fine.
Triggering those events seems to be very easy (just one-line calls), but if you want to, I can send you the lines I just inserted.

Since we did not hear anything about the chance of having such event-calls in the release of Moodle 1.9 we decided to show you the lines we had to insert into the core code to get our module to work.

Yu can you review and implement these? They look OK to me at a glance. The main thing is to have consistent event names that won't need changing.

Added (mostly) at the lines indicated, please verify that these changes are correct.

Cheers

Hello Yu....
thanks a lot for implementing these... Most of the lines are really perfect. It just seems like you did mix two little things. In moodle/user/edit.php you did add the lines that should be in moodle/login/change_password.php. So when a user updates his profile by himself a "password_changed"-event is triggered instead of a "user_updated"-event.
And when the user changes his password himself, no event is triggered.
So could you please fix this by putting the code from moodle/user/edit.php into moodle/login/change_password.php (near line 71) an the line "events_trigger('user_updated', $usernew)" into moodle/user/edit.php? Then everything works fine.
Thank you

EDIT:
And I forgot to mention that I would suggest to place the events_trigger-call for "category_updated" in moodle/course/category.php at the end of the the if clause (if (!empty($rename) and confirm_sesskey())). So in line 60. Because now this event is triggered too often. Even when an admin just navigates to this script via courses->add/edit courses and then clicks on a certain semester.

And for the group_deleted-event I forgot to ask for the courseid. Because just the groupid is no big help when the group has just been deleted. So perhaps it would be better to create something like:
$eventdata = new object();
$eventdata->group = $id;
$eventdata->course = $courseid;
events_trigger('group_deleted', $eventdata);

I'm sorry - that was my fault. I just forgot it.

Hi Peter sorry about that, should be fixed now, please double check =) Thanks

Thanks Yu. This is much better now. But it seems like you still forgot one line. Because there is still no "user_updated"-event triggered when a user himself updated something.
So you should insert "events_trigger('user_updated', $usernew);" into moodle/user/edit.php (near line 115). And then we are happy here.
Thanks a lot...

Hi Peter, sorry about that, hope you are happy now =)

Yes!! Very nice. Thank you. Now we can go on implementing. Thanks a lot.

now, that the 1.9_release ist out, we had to discover that some of the events described above are missing now and some of the others are stored elsewhere. I am not able to say if the events, that are now triggered from elsewhere, still work fine, because we are still testing.
but we definitely need the following events to be triggered again:

• group_created (that was in moodle/user/edit.php)
• group_updated (that was in moodle/user/edit.php)

please put them back in again, so we can go on testing. everything on our mod worked fine in the 1.9_development version and we hope that we just have to do some adjustments to have the mod working in the release version aswell...

thanks in advance

We write new and very interesting plugin for Moodle, but we needed some events from Moodle core:

• most of all - user enrolled/unenrolled to course (with user and course info)
• group created and group updated, as mentioned above

These are simple changes, easy to implement. Please make them.

I have discovered several problems in the event triggering, reopening and working on a fix, unfortunately the changes will not be backwards compatible

The first part is in cvs, list of changes:

• renamed the evens to be more consistent with general naming conventions (breaks backwards compatibility)
• moved the firing of events from UI related code to library functions
• changed eventdata structure in some events
• added some missing triggering of events and event types
• documented list of supported core events in lib/db/events.php
• the Events API now expects all input without magic quotes and returns data without magic quotes too (breaks backwards compatibility)
• removed user password changed event - this should be better implemented in auth plugin - the previous implementation was incomplete anyway

TODO:
1/ improve performance - going to add some static handler caches
2/ add enrolment related events

The previous (1.9.0, 1.9.1) events implementation in core should be considered buggy and incomplete, please update sites and any code that uses events API, thanks and sorry for the delay.

Petr

Please test the code and report any problems here, I will try to fix everything ASAP, thanks.

Should be fixed in cvs, please reopen if needed.

The final list of events triggered from core is (copied from lib/db/events.php):

==== user related events ====

user_created - object user table record
user_updated - object user table record
user_deleted - object user table record

==== course related events ====

course_category_updated - object course_categories table record
course_category_created - object course_categories table record
course_category_deleted - object course_categories table record

course_created - object course table record
course_updated - object course table record
course_deleted - object course table record

==== group related events ====

groups_group_created - object groups_group table record
groups_group_updated - object groups_group table record
groups_group_deleted - object groups_group table record

groups_member_added - object userid, groupid properties
groups_member_removed - object userid, groupid properties

groups_grouping_created - object groups_grouping table record
groups_grouping_updated - object groups_grouping table record
groups_grouping_deleted - object groups_grouping table record

groups_members_removed - object courseid+userid - removed all users (or one user) from all groups in course
groups_groupings_groups_removed - int course id - removed all groups from all groupings in course
groups_groups_deleted - int course id - deleted all course groups
groups_groupings_deleted - int course id - deleted all course groupings

==== role related evetns ====

role_assigned - object role_assignments table record
role_unassigned - object role_assignments table record

ooops, wrong target number

For now, I will just test that triggering the events had not broken anything. I am not going to write test event handler code and check that the events are received. I am sure that as people start to use the events, we will get told if anything is not working.

Note, I think it would be nice to have events relating to adding/editing/removing course modules, so I filed MDL-16203, but that is a separate issue.

Tested

User create/edit/delete
Course category create/edit/delete
Course create/edit/delete
Role assign/unassign
Group create/edit/delete
Group member add/remove
Grouping create/edit/delete

I assume the remaining bulk group events are triggered by course deletion, so closing issue.