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 |
| unsuspended | user_updated |
| silenced/unsilenced | 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_reason"and"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.