La invitación de API con el parámetro group_names devuelve 403 para el propietario del grupo a menos que sea administrador

Resumen

Un usuario no administrador que es propietario de un grupo de Discourse puede invitar con éxito a nuevos miembros con ese grupo asignado a través del diálogo de invitación de la interfaz web. La acción idéntica a través de la API REST (/invites.json, clave de API de ámbito global, Api-Username correcto) devuelve un error 403 invalid_access, pero solo cuando group_names/group_ids se incluye en la carga útil. Crucialmente, conceder al usuario el estado de Moderador no corrige la llamada a la API; solo concederle el estado de Administrador completo lo hace, a pesar de que el estado de Moderador es suficiente para todos los demás escenarios probados (interfaz web, invitación a la API sin grupo).

Entorno

  • Versión de Discourse: 2026.7.1
  • Tipo de clave de API: Ámbito global, CheriArchives = el nombre de usuario exacto del usuario de prueba

Pasos para reproducir

  1. Crea un usuario no administrador y no moderador (<userid>), y hazlo propietario del grupo <group_name>.
  2. Interfaz web, como <userid>: invitar sin grupo → éxito. Invitar con <group_name> asignado → éxito.
  3. API, como <userid> (clave de ámbito global, Api-Username=<userid>):
    • POST /invites.json sin group_names → éxito.
    • POST /invites.json con group_names=<group_name> (el mismo grupo del que es propietario) → 403 invalid_access.
  4. Promociona a <userid> a Moderador. Repite la llamada a la API con grupo del paso 3 → sigue siendo 403 invalid_access.
  5. Promociona a <userid> a Administrador. Repite la llamada a la API con grupo del paso 3, misma clave, misma carga útil → éxito.

Comportamiento esperado

Dado que la propiedad del grupo por sí sola es un permiso suficiente para que un usuario no de personal asigne ese grupo en una invitación a través de la interfaz web, la API —autenticada como el mismo usuario a través de Api-Username— debería respetar el mismo permiso. Al menos, el Moderador (que es personal) no debería comportarse de manera idéntica a un usuario sin privilegios aquí; el hecho de que el Moderador falle de manera idéntica a un usuario sin rol, y solo el Administrador tenga éxito, sugiere que la ruta de código de la API comprueba específicamente user.admin? en lugar de la propiedad del grupo o incluso el estado general de personal (user.staff?, que es verdadero para los moderadores).

Comportamiento real

La API devuelve un error 403 en cualquier invitación con grupo a menos que el usuario que actúe sea un Administrador completo. La propiedad del grupo (verificado que funciona a través de la interfaz web) y el estado de Moderador/personal (verificado mediante prueba de promoción directa) son ambos insuficientes para la ruta de la API, a pesar de que cualquiera de ellos es suficiente a través de la interfaz web o para el caso de la API sin grupo.

Pregunta para el equipo de Discourse

¿La ruta de código de invitación con grupo autenticada por API requiere explícitamente user.admin?, en lugar de comprobar la propiedad del grupo o user.staff? de la manera en que lo hace la ruta de la interfaz web / autenticada por sesión? Si es así, ¿es intencional (restricción específica de la API no documentada) o es un error donde la comprobación del guardián de la API se desvía de la comprobación del guardián de la web para esta acción?

Estoy dispuesto a proporcionar registros completos de solicitud/respuesta (clave redactada) si se solicita.