Evitar que los usuarios cambien sus nombres completos

Hola a todos,

En el foro que administramos, aunque damos mucha libertad en el nombre de usuario, exigimos (en los términos de uso) que los usuarios proporcionen sus nombres completos y no los cambien, excepto para reflejar cambios legales de nombre. Todavía no tenemos muchos usuarios (menos de 250), pero ya algunas personas empiezan a no respetar esta regla. Por lo tanto, necesitamos una forma de hacerla cumplir.

En resumen, necesitamos que un nombre completo solo pueda ser cambiado por un moderador o un administrador después de que la cuenta haya sido aprobada. ¿Hay alguna forma de lograr esto en Discourse? He revisado la documentación sin éxito.

Si no es así, ¿se podría añadir esta función al código?

Gracias.

3 Me gusta

Una solución simple pero evitable es ocultar el botón de edición con CSS. Las personas astutas podrían editarlo de todos modos. Para forzar su conservación, necesitarías un plugin o quizás sso.

4 Me gusta

Gracias por tu respuesta. ¿Sabes si ya existe algún plugin de este tipo? Si no, intentaré entender cómo hacerlo, pero hace mucho tiempo que no programo nada :frowning:

2 Me gusta

Parece que el plugin no existe, pero la solución alternativa de CSS es simplemente Inspeccionar desde Firefox o Chrome, hacer clic en el cuadro que desea ocultar y editar el CSS en el tema:

2 Me gusta

Creo que la opción más sólida aquí es usar un proveedor de autenticación externo (OAuth lo que sea) con la opción “auth overrides username”:

Anula el nombre completo local con el nombre completo del sitio externo en cada inicio de sesión y evita los cambios locales. Se aplica a todos los proveedores de autenticación.

1 me gusta

Eso funcionará, pero incluir servicios de terceros no es una buena opción para muchos de nosotros que estamos de acuerdo con dejar que los usuarios elijan su proveedor de correo electrónico.

Por “externo”, no me refiero a “terceros”, sino a “externo a Discourse”. Podrías usar una solución de terceros o podrías ejecutarla tú mismo.

La confianza en nosotros mismos es diferente a confiar en el equipo central de Discourse, son profesionales de primer nivel que construyeron todo.

Mi punto es que tu solución más fuerte no es la más elegante, que debería ser deshabilitar la opción desde un interruptor.

1 me gusta

Hola,
Gracias por la sugerencia, pero lamentablemente, actualmente no es una opción. No tenemos un SSO central y su gestión es mucho más de lo que quiero emprender.

Actualmente, la manipulación de CSS es probablemente hasta dónde puedo llegar. Lo que estoy gestionando es un foro de club, con todos los miembros identificados, y forzar este cambio a pesar de que simplemente esté deshabilitado (y prohibido en las reglas) haría que la cuenta del usuario se convierta en solo lectura o se desactive por completo.

Gracias @satonotdead por los enlaces que proporcionaste, revisaré este contenido y veré si puedo gestionar el cambio fácilmente. A largo plazo, cuando tenga tiempo (puede que necesite esperar 15 años o más hasta la jubilación para esto :sweat_smile:), puedo optar por invertirlo en escribir un complemento…

2 Me gusta

¿Funcionaría una solución híbrida @AriesFR?

Si sigues la sugerencia de Jay @pfaffman de ocultarlo con CSS, entonces crea un campo de usuario personalizado y ten la configuración como:

:thinking:

2 Me gusta

De acuerdo, de hecho podría funcionar, pero todavía quiero que aparezca junto al nombre de usuario, como está especificado actualmente para el nombre completo.

Por ahora, ocultar la sección del nombre completo de la sección de actualización del perfil del usuario será una solución temporal aceptable. Todavía puedo manejar excepciones de usuarios demasiado curiosos para su propio bien.

Todavía no entiendo por qué parece ser un problema tener esta opción de bloqueo en el producto base, como la tenemos para el nombre de usuario… parece muy dogmático.

[MODO PROVOCACIÓN ACTIVADO]
Un poco como no aceptar permitir firmas de usuario porque es por nuestro propio bien.
[MODO PROVOCACIÓN DESACTIVADO]

Lo revisé; ocultar el campo con la API se puede hacer, pero no encuentro ningún dato en el que pueda confiar para saber si ese usuario está aprobado o no (en el contexto de la página de preferencias) :thinking:

Esto es lo que tengo por ahora.
No estoy seguro de si debería sentirme mal; tal vez un poco hacky aquí. :smile:

js

<script type="text/discourse-plugin" version="0.8">

const { setting } = require("discourse/lib/computed");

api.modifyClass("controller:preferences/account", {
  pluginId: "hide-name-in-preferences",

  get canEditName() {
    const enables_name = setting("enable_names");

    if (enables_name && this.isCurrentUser && !this.model.staff) {
      if (this.model.name) {
        // Ocultar solo el campo de entrada (el nombre se muestra)
        this.model.can_edit_name = false;
      } else {
        // Ocultar toda la sección
        return false;
      }
    }

    return enables_name;
  },
});
    
</script>
1 me gusta

No es un problema ni un dogma, la mayoría de nuestras funciones se priorizan en función de la demanda, y no ha habido mucha demanda para esto.

9 Me gusta

Gracias @Arkshine, esto se parece mucho a lo que necesito. Solo tendré que investigar cómo incluir esto en mi entorno :slight_smile:, pero probablemente lo tendré incluido para este fin de semana.

Gracias, puedo entender la priorización, aunque el mecanismo global ya está presente y, por lo que pude ver, ha sido solicitado varias veces por los usuarios. Si el parche es realmente tan simple como lo que Arshkine acaba de proporcionar, me parece que fue una decisión consciente de NO otorgar la misma “cortesía” a este campo que a los otros.

No me malinterpretes, este es un software maravilloso que se desarrolló aquí. Por lo que puedo decir del foro que ayudo a administrar, parece funcionar sin problemas, y sé lo difícil que es. Simplemente no estoy de acuerdo con todas las decisiones que se tomaron, y considero que algunas de las justificaciones que se dieron a veces son dogmáticas o autoritarias. Esto no impide que sea el mejor disponible hoy en día.

Saludos

Un componente temático puede ser eludido utilizando el modo seguro o modificando otras cosas en el navegador.

En su mayor parte, el desarrollo está impulsado por personas que están alojadas en CDCK/Discourse.org, ya que de ahí proviene el dinero. A veces se agregan funciones si a mucha gente le gusta/necesita una función, pero si esas personas no pagan dinero a CDCK, debe ser muchísima gente, o una función que parece que a muchos clientes que pagan les gustará tener. Tenga en cuenta que no trabajo para ellos, por lo que esta es meramente mi observación de los últimos (casi 8) años.

5 Me gusta

¡De hecho! Es posible que desees deshabilitar la configuración habilitar modo seguro para que los no administradores no puedan usarlo.

3 Me gusta

¡OH! Me había perdido eso. Todavía se puede eludir por personas que son ingeniosas con la consola de desarrollador del navegador.

1 me gusta

¡Gracias, no vi este parámetro, ahora está desactivado!

1 me gusta

Especulando: No me sorprendería si la mayoría de las personas que quieren esto y son clientes de pago ya tienen algún tipo de SSO. Por lo tanto, se convierte aún más en una característica de nicho para todos los demás.

3 Me gusta

No parece que estén haciendo nada para autenticar el nombre completo que sus usuarios proporcionan al registrarse. Entonces, si lo cambian de Bob Jones a Sam Smith, ¿cómo saben que alguno de los nombres es suyo?

2 Me gusta