Webservice activity should trigger create/modify/trigger events

Setting to critical, since not getting events for some of the objects we currently expose means that we won't have an audit trail for them (email norifications, activity log).

Before diving into what looks to be a fairly complex fix that will degrade the user experience of the person annotating the interfaces, I'd like to naively suggest moving these notifications out of the browser layer and into the object layer. Is there a reason why we call notify(SQLObjectModifiedEvent(bug, bug_before_modification, ['private'])) in BugSecrecyEditView.change_action() and not in Bug.setPrivate()?

Moving notifications into the methods and resources we expose, as we expose them, would solve the problem without requiring any changes to the annotation system or LAZR. It would also prevent this problem from happening again if we add another interface to the object layer in the future. It seems like this could be made one of the housekeeping tasks we take care of as we expose our objects through the web service.

One reason we don't do it in the database layer is that we batch things together into one event. For example, if we edit both the status and importance, we issue only one event instead of two.

The other quite important reason is that in the database we don't always have access to the user doing the change. For example, if you set an attribute on the object, the database layer don't know which user did the change.

Not to mention that changing the way we currently issue notification would be a lot of work; a lot more than making sure that the API layer issues events. This is quite a serious bug, and it should get fixed before people start to use the API seriously.

- PUT/PATCH should fire an appriate Modifed event
- DELETE should fire the appropriate

But for named operation, the method itself should be modified to fire the event themselves. There is no point in making the event fired at the API layer, since the fact that events are sent in browser code already is the source of much that skew.

Here's the final compromise as implemented by me:

PUT/PATCH fires a SQLObjectModifiedEvent.
All write operations except for factory operations fire a SQLObjectModifiedEvent.
Factory operations fire no event.

We don't support DELETE so punt on that.
Over time our write operations will fire their own events and we can get rid of the blanket fire-on-write-operation.