Watch out with Zope events on Plone

Today I ran into a bug caused by some unexpected behaviour with the zope.app.event.interfaces.IObjectModifiedEvent and zope.app.container.interfaces.IObjectRemovedEvent Zope events in a Plone context.

The bug was: whenever a user would delete a piece of content, the catalog would not be cleaned up properly, which confused the plone folder_contents view which is catalog based. Also, when creating content, strange "/path/to/parent/portal_factory/Contenttype" objects catalog entries were created (and not cleaned up).

It turned out this was caused by an eventhandler I wrote that would reindex a parent object if a childobject was modified. However, this event (IObjectModifiedEvent) is also triggered when your object is still in the portal_factory (causing the strange catalog entry), and when a parent object is (recursively) deleted. When the parent traverses to the subitem to delete, it'll get an IObjectRemovedEvent which will cause the parent-to-remove to reindex itself (probably *after* the catalog has been cleared for the parent), which leaves the unexplained records in the catalog.

So be careful when using these events and make sure you're not changing any/too much context or modifying the catalog in any other way!

Products.Archetypes.interfaces.IObjectEditedEvent and Products.Archetypes.interfaces.IObjectInitializedEvent are good alternatives for catching object modifications, but I haven't yet found an event that is usable to properly handle deletion. Perhaps the deprecated manage_beforeDelete can help.

UPDATE

OFS.interfaces.IObjectWillBeRemovedEvent appears to be suitable. It's invoked before the object is deleted, and it doesn't have the sideeffects described above.