Hay una serie de acciones que esperaría (y me gustaría) que generaran eventos de webhook de usuario, pero no lo hacen. Antes de informar errores (o enviar PR), me gustaría tener una mejor idea de por qué es así.
| acción | evento de usuario esperado |
|---|---|
| cuenta desactivada por el administrador | user_logged_out |
| cuenta anonimizada por el administrador | user_logged_out |
| el usuario cierra sesión por sí mismo con el botón “Cerrar sesión en todos” | user_logged_out |
| — | — |
| añadido a un grupo | user_updated |
| eliminado de un grupo | user_updated |
| nivel de confianza aumentado/disminuido | user_updated |
| se concede/revoca el estado de moderador | user_updated |
| se concede/revoca el estado de administrador | user_updated |
| no suspendido | user_updated |
| silenciado/no silenciado | user_updated |
- El primer grupo de tres son todas acciones que resultan en un cierre de sesión global, invalidando todas las sesiones del usuario, pero a diferencia de otras acciones similares (por ejemplo, el usuario cerrado por el administrador), estas tres no generan un evento user/user_logged_out (ni ningún otro evento).
- Ser añadido/eliminado de un grupo genera un evento group_user, pero no un evento user. Los eventos group_user no son muy útiles por sí solos, ya que solo contienen los ID numéricos internos de los grupos y usuarios. Por otro lado, el registro
"user"enviado al ocurrir un evento user contiene información muy útil para todos los grupos a los que pertenece un usuario, incluidos los nombres de los grupos y detalles sobre las relaciones del usuario con los grupos. - Cuando se aumenta el nivel de confianza de un usuario, se emite un evento user_promoted, que contiene datos muy similares, pero no idénticos, a un evento user. Cuando se disminuye el nivel de confianza de un usuario, no se emite ningún evento similar.
- No se emiten eventos user cuando cambian los estados de moderador o administrador. (Hay evidencia indirecta específica del usuario de las acciones de concesión a través de eventos group_user; no hay evidencia específica del usuario de las acciones de revocación).
- Suspender a un usuario emite un evento user/user_logged_out (con los campos
"suspended_reason"y"suspended_till"que indican la suspensión), pero no hay ningún evento cuando un usuario es no suspendido. No se emiten eventos en absoluto cuando un usuario es silenciado o no silenciado.
¿Son intencionales algunas de estas omisiones?
Mi pensamiento general es “Si los datos en el registro "user" de un evento user hubieran cambiado, entonces se debería emitir un evento user”. Eso probablemente abarca más situaciones que actualmente no evocan eventos. Sin embargo, las pocas que he detallado en la tabla anterior son las que más me importan en este momento porque todas implican cambios en el estado de autorización de un usuario.