Al usar el endpoint /admin/users/sync_sso para sincronizar datos de SSO, no es posible eliminar el nombre de alguien de la cuenta, incluso si no es obligatorio. En otras palabras, no es posible cambiar el nombre de una cuenta de algo a nada. Esto ocurre con full_name_required = false (y sso_overrides_name = true).
Creo que el problema está aquí:
pero temo que mi conocimiento de Ruby/Discourse no es suficiente para enviar un PR.
Esto me parece una solicitud de #funcionalidad. Por ahora, puedes usar la API de administración para borrar nombres en casos como este. Consulta:
Lo siento, pero no estoy de acuerdo. No veo cómo esto puede ser una solicitud de función y no un error.
Entiendo que hay otros puntos de acceso de la API que se pueden utilizar. Pero el punto principal de /admin/users/sync_sso es precisamente mantener este tipo de datos, bueno, sincronizados. Ya permite establecer el campo de nombre de cuenta; eso funciona. Sin embargo, asume que el nombre es siempre un campo obligatorio y no permite establecerlo en blanco. Por lo tanto, no se puede utilizar para mantener los datos sincronizados.
El código a continuación parece hacer que funcione como se espera en mi entorno de pruebas, pero, de nuevo, no me siento lo suficientemente seguro para enviar un PR en este momento. Siéntete libre de usarlo/adaptarlo, etc.
- if SiteSetting.sso_overrides_name && user.name != name && name.present?
- user.name = name || User.suggest_name(username.blank? ? email : username)
+ if SiteSetting.sso_overrides_name && user.name != name
+ if SiteSetting.full_name_required && name.present?
+ user.name = name || User.suggest_name(username.blank? ? email : username)
+ else
+ user.name = name
+ end
Es una solicitud de funcionalidad, la semántica es ambigua. La falta de nombre podría significar
Estás pidiendo un cambio en el protocolo. Por lo general, prefiero la explicitud para evitar una API confusa.
Ahora entiendo tu punto.
Una vez más, no conozco lo suficiente los detalles internos (ni Ruby)… pero ¿no hay forma de saber si el campo name fue incluido en esa solicitud? Si no está presente en absoluto, no tocar el campo name de la cuenta. Si se proporciona el campo name, establecerlo (si está en blanco, borrarlo). ¿Esto no respetaría ese protocolo/comportamiento donde solo se sincronizan los campos proporcionados?
Perdona si esto no tiene sentido, solo estoy tratando de comprender según lo que entiendo.
El problema es que la semántica del protocolo actual, donde el parámetro “name” existe y está establecido en vacío, es equivalente a la ausencia del parámetro “name”. Simplemente no lo modifica.
Un cambio aquí implica una alteración de la semántica del protocolo. Podríamos, supongo, modificarlo para que name= signifique “dejar name en blanco”, y la ausencia de name signifique “no tocar name”, pero como la gente ya depende del comportamiento anterior, esto constituye técnicamente un cambio incompatible.
¿Puedes explicar por qué estás eliminando los nombres?
No estamos eliminando los nombres de todos; los usuarios actualizan sus propios datos cada vez que actualizan su cuenta en nuestro sitio web (proveedor de SSO). Confiamos en /admin/users/sync_sso para mantener sincronizados los datos (nombre de usuario, nombre, avatar, etc.) en su cuenta de Discourse. El campo nombre es opcional y puede dejarse en blanco/vacío.
Acabo de darme cuenta de que el problema no ocurre solo con el nombre, sino también al actualizar la biografía, el avatar, etc.: no es posible mantener esos registros de SSO sincronizados a través de /admin/users/sync_sso si necesitan actualizarse a blanco/vacío, independientemente de si son campos obligatorios o no.
Entiendo el punto de que algunas personas pueden depender del comportamiento existente (aunque ¿nadie había reportado este problema antes?), pero si este es el protocolo, parece que tiene limitaciones significativas para su propósito de sincronizar registros de SSO.
También me está afectando este problema: los usuarios individuales no pueden eliminar su propia información personal (nombre, avatares, biografía, campos personalizados, etc.) de Discourse, lo que tiene consecuencias, como puedes imaginar.
Estoy de acuerdo en no cambiar la semántica de cómo funciona actualmente, pero ¿no podrían permitirnos establecer estos atributos como false en la carga útil de SSO o algo similar para ser explícitos al eliminarlos?
Anteriormente, sorteábamos esta limitación de SSO componiendo la llamada a /admin/users/sync_sso con otra llamada al endpoint /u/{username} solo para borrar el nombre (si el nuevo valor para el nombre estaba vacío).
Sin embargo, esto también parece haber dejado de funcionar en algún momento de una versión reciente, posiblemente porque verifica si sso_overrides_name = true antes de actualizar el nombre.
Por lo tanto, tal como está, al usar SSO y sso_overrides_name = true, ahora parece imposible que el proveedor de SSO borre el campo de nombre en Discourse a través de la API.
¿Ves alguna solución a esto, @sam?
¿Supongo que un parámetro adicional para nuestra ruta sync_sso está en orden? ¿Algo como &clear_name no estoy seguro. Esto se siente como un caso extremo. ¿Cuál es el caso de uso para nombres en blanco? Tal vez simplemente establécelo en nombre de usuario si no tienes ninguno y la interfaz de usuario puede suprimir duplicados.
Me resulta confuso que consideres esto un caso extremo, así que supongo que debes estar acostumbrado a instancias en las que el nombre es el campo obligatorio.
Nosotros lo tenemos al revés: el nombre de usuario es lo que todos deben tener, y el nombre es un campo opcional (usamos prioritize_username_in_ux = true y full name required = false). Piensa en las cuentas de Twitter, donde todos deben tener un nombre de usuario/identificador, y opcionalmente también pueden tener un nombre. No creo que sea un escenario extremo querer borrar el campo de nombre (u otros datos personales).
Ahora mismo, una vez que se ha introducido un nombre, es imposible eliminarlo. Esto era una limitación de sync_sso que solucionamos con una llamada adicional a la API para actualizar al usuario, pero ahora eso tampoco funciona.
Lo consideramos, pero induce a algunas personas a asumir que el nombre de usuario de uno es también su nombre real: dirigimos un foro internacional y a menudo no está claro qué es el nombre de una persona y qué es un nombre de usuario (aparte de su posicionamiento en la interfaz).
Debo mencionar que si la memoria no me falla, ocurre exactamente el mismo problema al eliminar el avatar de uno a través de sync_sso, ya que creo que tampoco funciona; lo solucionamos proporcionando nuestra propia URL para un avatar predeterminado.
Si hay varios campos que uno no puede borrar de alguna manera, ¿quizás una matriz (o lista csv) de qué campos borrar/restablecer?
¿Qué se necesitaría para llegar a un acuerdo sobre una forma de lograr esto? Estoy feliz de implementar cualquier cosa del lado: un nuevo parámetro, un valor especial, una segunda llamada a la API. Pero la situación actual, desde mi perspectiva, no es un caso extremo. Al igual que @mentalstring arriba, estoy sincronizando con una fuente de verdad externa donde establecer una imagen de perfil y un nombre para mostrar son opcionales. El usuario tiene permitido no tenerlos. Discourse permite que no se establezcan. Si no usas SSO, puedes establecerlos y eliminarlos libremente. DiscourseConnect rompe esto: una vez que se establecen, nunca se pueden eliminar, lo que en mi opinión es un (muy pequeño) error.
Entiendo la preocupación sobre cambiar el protocolo donde vacío actualmente significa sin cambios. Personalmente no estoy de acuerdo, creo que es una forma sencilla y razonable de interpretar el protocolo y el riesgo es mínimo: sería muy extraño que los sistemas se implementaran de tal manera que siempre envíen valores de nombre y avatar_url, pero a veces los establezcan en blanco, y esperen que eso signifique mantener el valor antiguo. Y si hay alguno que lo haga, la consecuencia es solo que el nombre y el avatar se desactiven, y debería ser una solución fácil.
Pero de todos modos, no quiero discutir ese punto, pero sí quiero argumentar que esta es una característica necesaria. Estoy dispuesto a hacer el PR, solo quiero saber qué solución sería aceptada.
Muchas gracias de antemano.
Dado que esto ocurre con al menos name y avatar_url y posiblemente otros (¿creo que website también?), ¿quizás un parámetro reset_fields con una lista de campos para borrar en lugar de varios clear_x individuales?
Para nosotros ya sería útil si pudiéramos solucionarlo con llamadas adicionales al endpoint /u/{username}, pero eso también dejó de funcionar en algún momento.