There are a bunch of actions that I would expect (and would like) to generate webhook user events, but they don’t. Before I go filing bug reports (or submitting PR’s), I’d like to get a better idea of why that is.
|action||expected user event|
|account deactivated by admin||user_logged_out|
|account anonymized by admin||user_logged_out|
|user logs out self via “Log out all” button||user_logged_out|
|added to a group||user_updated|
|removed from a group||user_updated|
|trust level increased/decreased||user_updated|
|moderator status granted/revoked||user_updated|
|admin status granted/revoked||user_updated|
- The first group of three are all actions that result in a global, all-sessions-invalidated logout of the user — but unlike other similar actions (e.g., user logged out by admin), these three don’t generate a user/user_logged_out event (or any other event).
- Being added/removed from a group generates a group_user event, but not a user event. The group_user events aren’t very useful by themselves, since they only contain the internal numeric id’s of groups and users. On the other hand, the
"user"record sent upon a user event contains really useful information for all the groups to which a user belongs, including the names of the groups and details about the user’s relationships with the groups.
- When a user’s trust level is increased, a user_promoted event is emitted, which contains data which is very similar to, but not quite the same, as a user event. When a user’s trust level is decreased, no similar event is emitted at all.
- No user events are emitted when moderator or admin status changes. (There is indirect user-specific evidence of grant actions via group_user events; there is no user-specific evidence of revoke actions.)
- Suspending a user does emit a user/user_logged_out event (with
"suspended_till"fields indicating the suspension)… but there is no event when a user is unsuspended. No events whatsoever are emitted when a user is silenced or unsilenced.
Are any of these omissions on purpose?
My general thinking is “If the data in a user event
"user" record would have changed, then a user event should be emitted.” That probably encompasses more situations that do not currently evoke events. However, the few I itemized in the table above are the ones I care about the most at the moment because they all involve changes to a user’s authorization status.