Using /admin/users/sync_sso endpoint to sync SSO data, it is not possible to remove someone’s name from the account, even if it is not required. In other other words, it’s not possible to change an account’s name from something to nothing. This is happening with full_name_required = false (and sso_overrides_name = true).
I believe the issue is here:
but I’m afraid my knowledge of Ruby/Discourse isn’t that hot to submit a PR.
This feels like a feature request to me. At the moment you can use the admin API to clear names in cases like this. See:
Sorry, but I disagree. I don’t see how this can be a feature request and not a bug.
I understand there’s other API endpoints which can be used. But the main point of /admin/users/sync_sso is precisely to keep this sort of data, well, in sync. It already allows to set the account name field — that works. But, it assumes name is always a required field and doesn’t allow it to be set it to blank. So it can’t be used to keep data in sync.
The code below seems to make it work as expected on my sandbox, but again, I don’t feel confident enough to submit a PR at this point. Feel free to use it/adapt it, 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
Its a feature request, the semantics are ambiguous. Lack of name could mean
You are asking for a protocol change here. I usually prefer explicitness so we don’t have a confusing api.
I see your point now.
Once again, I don’t know the internals (or ruby) enough… but there’s no way to know if the field name was provided on that request? Not present at all, don’t touch the name field of the account. Field name provided, set it (if blank, clear it). Wouldn’t this respect that protocol/behavior where only the provided fields are synched?
Sorry if this makes no sense — just trying to grasp from what I understand.
The problem is that the protocol semantics now of “name” param is there and set to blank, is the same as no “name” param. It simply does not touch it.
A change here is a change to protocol semantics. We could I guess change is so name= becomes name is blanked, and absence of name means “don’t touch name”, but people already rely on the old behavior so this is technically a breaking change.
Can you explain why you are removing names?
We are not removing everyone’s names — the users are updating their own data whenever they update their account on our website (SSO provider). We rely on /admin/users/sync_sso to keep data in sync (username, name, avatar, etc) in their Discourse account. Name is an optional field and can be set to blank/empty.
I just realized the issue happens not just with name but also with updating bio, avatar, etc: it’s not possible to keep those SSO records in sync through /admin/users/sync_sso if they need to be updated to blank/empty, regardless whether they are mandatory fields or not.
I understand the point that people may be relying on existing behavior (although nobody reported this issue before?), but if this is the protocol, it seems it has significant limitations for its purpose of synchronizing SSO records.
I’m also getting bitten by this, individual users are unable to remove their own personal information (name, avatars, bio, custom fields etc) from Discourse which has ramifications as you can imagine.
Agree with not changing the semantics of how it works now but could you not allow us to set these attributes as false in the SSO payload or something similar to be explicit about removing them?
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.