@jreese : any ideas on how we should go about doing this?

It appears that creating/modifying issues through the SOAP API doesn't trigger any notification e-mails either.

Is that caused by this issue, or should I open a separate issue that problem?

@thijsputman : there's no need to open a separate issue, we'll track all events using this one.

Rombert: surely this is just a case evaluting the positioning of hooks so that the hooks are consistent? i.e. I assume that the soap api doesn't block/disable the event hooks/plugins, so if event's are not getting fired, it feels like we've got events in the wrong place...

Usually the SOAP API needs to fire the plugin events itself since the web UI triggers them directly as well.

There are different types of events, i think they could be classified on these two groups:
1) Events that affects web page: layout, form, etc
2) Events related to core functionality: bug update, actions, etc

Most events are of type 1, and makes sense on the web frontend.
Type 2, however, should be valid on every context, for example: a bug can be updated from a user action on the web page, a soap api call, or a direct call to core apis from plugins/custom code.
Currently these events are triggered only from the web frontend.

I think those should be moved into the core api. For the current issue, soap api ideally would call core api functions, soif the events are defined there, the behaviuor would be consistent.

(On a related issue, email notifications may have the same problem, since they are triggered from the caller, not the actual performer of the action)

Unassigned after a long time of inactivity.