Configuration/hooks/log caldav action
- $put_action_type - exactly INSERT, UPDATE or DELETE
- $uid - the UID value from the first non-VTIMEZONE component of the iCalendar data
- $user_no - DAViCal's ID for the usr making the change.
- $collection_id - DAViCal's ID for the collection containing the resource.
- $path - DAViCal's version of the path: everything after the 'caldav.php' in the URL.
This hook is being called from within a database transaction in a critical part of the calendaring system. If you break stuff then you get to be responsible for putting all of the pieces back together.
If you have a database error in your code the update transaction will fail and be rolled back. Obviously you could use this as a hack to deny updates for some calculated reason, but if you need that it's probably better to ask the developers for a different hook.
This hook is being called from within the critical path of a database change operation. It should not muck around.
On the other hand, with many calendars this is a low rate of change activity, so maybe it will be OK if you take a second or two to confirm you updated some external system before returning to DAViCal and letting it continue with the commit...
The recommended approach for using this hook is to simply write the data you've been given into some kind of a queue, and let something else do the work with it while you return control back to DAViCal.
There's an example of a hook like the recommended approach in the DAViCal
inc subdirectory: here