¿Extender controlador existente?

Desarrollador
1

Hola a todos, espero estar publicando esto en el lugar correcto. Estoy intentando desarrollar un plugin para mi nuevo sitio web de Discourse.

Hice un fork del repositorio de ejemplo aquí, logré que funcionara un Plugin Outlet, luego me encontré con un muro y empecé a sentirme bastante perdido y confundido. Recientemente estoy empezando a dominar los frameworks MVC de PHP como Laravel, pero soy MUY nuevo en los frameworks de JS. Nunca he tocado Ruby, Rails o Ember antes.

El Problema

Mi sitio web es para una comunidad de HOA. Lo que estoy intentando hacer es recopilar y guardar algunos campos de datos adicionales por usuario:

  • legal_name (cadena)
  • is_owner (booleano)
  • is_resident (booleano)
  • building (cadena) - representando el número de su edificio
  • unit (cadena) - representando el número de su unidad
  • … y algunas otras variables internas, como si un moderador los ha confirmado.

Quiero hacer que estos campos sean obligatorios para el registro de usuarios. Eso significa modificar el formulario de registro de usuarios. Me conecté al outlet create-account-after-password y logré mostrar algunos campos adicionales, pero obviamente esto no lo hace funcional.

Creo que necesito extender el controlador en app/assets/javascripts/discourse/app/controllers/create-account.js, no solo para capturar los nuevos valores del formulario cuando se envían, ¡sino incluso para algo tan (aparentemente) básico como usar el nombre del sitio this.siteSettings.title en un campo de traducción de client.en.yml! (Ahora mismo, los campos adicionales en mi formulario de registro tienen como encabezado: “¿Cuál es tu conexión con [valor de %{title} faltante]?”. Lo cual obviamente no es bueno).

Cuanto más intentaba buscar respuestas, más preguntas tenía y más grandes se volvían. Diferentes guías que intenté seguir aparentemente fueron escritas para diferentes versiones de Discourse. El repositorio de ejemplo del plugin tiene cosas que no entiendo. ¿Cuál es la diferencia entre una ruta del lado del cliente y una ruta del lado del servidor? ¿Cuál es la diferencia entre un plugin y un módulo? Estoy tan perdido.

Si alguien pudiera ofrecer alguna ayuda, estaré muy agradecido. Gracias de antemano.

2 Me gusta
2

Creo que podrías hacerlo con Creating and configuring custom user fields

3 Me gusta
3

¡Gracias! Eso no proporciona toda la funcionalidad que creo que quiero, pero definitivamente me hace reflexionar sobre si esa característica puede ayudarme a alcanzar mis objetivos.

De cualquier manera, creo que todavía necesito responder a la pregunta original de cómo extender los controladores existentes usando un plugin. ¿Es posible algo así?

4

¿guardarlo solo para mostrarlo en algún lugar? ¿qué quieres hacer con estos datos? tengo la impresión de que quieres almacenarlos para alguna otra funcionalidad en lugar de solo mostrarlos en algún lugar del foro.

6

Esto se puede lograr sin ninguna programación con Creating and configuring custom user fields

3 Me gusta
8

¿qué quieres hacer con estos datos? Tengo la impresión de que quieres almacenarlos para alguna otra funcionalidad en lugar de simplemente mostrarlos en algún lugar del foro.

Bueno, mi esperanza/visión definitiva era:

1. Moderación por niveles

Otorgar a los propietarios de cada unidad en la comunidad poderes de moderador sobre ÚNICAMENTE los residentes de su unidad.

Teniendo en cuenta que hay cerca de 200 unidades en nuestra comunidad, no parecía factible utilizar la función de grupos para lograr esto. Ver también el punto #3 a continuación, con el que los grupos también entrarían en conflicto.

2. Experiencia de usuario de registro

La experiencia de usuario perfecta en mi opinión también haría que el menú desplegable de “unidad” en el formulario de registro reaccionara dinámicamente a la elección del usuario en el campo “edificio”, para ofrecer solo las unidades que se encuentran en ese edificio. (Iba a encontrar alguna manera de analizar un archivo de configuración JSON para esto cuando Discourse se inicializara).

3. Configuración de privacidad de campos

Quería ofrecer a cada usuario la opción de ocultar su número de edificio y/o unidad a otros usuarios que no estuvieran en su unidad.

Tengo la impresión de que la función principal de campos personalizados ofrece esta opción solo por campo (no por usuario) y también solo a los administradores, no a los propios usuarios.

4. Estilo elegante

Esto sería más bien una guinda del pastel, pero en lugar de mostrarlo como algo como “Propietario: sí”, quería darle al sistema conocimiento especial de estos campos para estilarlos de manera diferente en los resúmenes de usuario. Como poner un icono SVG de escritura y una marca de verificación si un moderador ha confirmado su estado (o un icono de casa para los residentes). Ese tipo de cosas.

Así que, sí…

Quizás soy demasiado exigente aquí, pero siento que una vez que supere la curva de aprendizaje para lograr la funcionalidad principal, los elementos más pequeños de la lista de deseos se volverán casi triviales.

Muchos de los residentes de mi comunidad son personas mayores con poco o ningún conocimiento informático. Tengo serias preocupaciones de que algunos residentes no quieran adoptar y usar mi sitio web de Discourse simplemente porque es nuevo y no Facebook, y mucho menos debido a problemas de uso genuinos como la privacidad de la dirección o la entrada no validada de números de edificio/unidad.

2 Me gusta
9

Los grupos funcionarán bien para ese propósito, y puedes tener fácilmente 200 grupos.
Todo lo que necesitarías hacer es mapear el campo manualmente o programáticamente a un grupo. Pero también podrías querer que las personas envíen algún tipo de “prueba” después del registro.
Podrías hacerlo manualmente, codificarlo tú mismo, usar el plugin de asistente personalizado de Pavilion para eso.

Eso es cierto, pero podrías tener usuarios que quieran hacerlo público y mostrar ese campo en otro lugar, es decir, tener un campo de edificio “privado” y un campo de edificio “público”.

2 Me gusta
10

Si necesitas agregar características, quieres crear un componente de tema o un plugin, no bifurcar discourse.

Puedes hacerlo en un componente de tema, por lo que no necesitas un plugin para eso, pero si estás creando un plugin, también puedes incluir los cambios en el frontend en el plugin. Desarrollo de plugins de Discourse - Parte 1 - Crear un plugin básico. Buscar plugins que agreguen funcionalidad similar también es una buena opción. Hay un repositorio de Discourse llamado all-the-plugins que puedes usar para buscar ejemplos.

Tener versiones públicas vs. privadas de esos campos como se sugiere parece una buena solución, pero también puedes agregar campos de usuario en un plugin y controlar cómo y si esos campos se agregan al serializador para mostrarlos.

Esto es lo que hacen los componentes de tema. Guía de referencia rápida para desarrolladores de temas podría ser un comienzo.

2 Me gusta
11

¿No creo que TS tuviera la intención de bifurcar discourse??

3 Me gusta
12

Parece que el repositorio al que enlazó es una bifurcación y no un plugin.

2 Me gusta
13

image

Hacer un fork de discourse-plugin-skeleton parece un buen comienzo para escribir un plugin para mí…

5 Me gusta
14

¡De acuerdo! ¡No sé qué creo que vi! No sé cómo pasé por alto que era un fork. :person_shrugging:

Pensé que había buscado plugin.rb…

2 Me gusta
15

Está bien, aprendí cosas de esta conversación como resultado :grin:

2 Me gusta
16

¡Gracias @RGJ por aclararme eso! :sweat_smile: Sí, definitivamente nunca habría bifurcado Discourse solo por esto.

17

también puedes añadir campos de usuario en un plugin y controlar cómo y si esos campos se añaden al serializador para mostrarlos.

¿Esto incluye añadirlos al modal de “crear cuenta” y hacerlos obligatorios? ¿Puedes indicarme algún ejemplo o guía sobre cómo hacerlo?

Ya he leído la guía completa que enlazaste “Desarrollo de Plugins de Discourse”. Ahí es donde empecé. Al final, la única funcionalidad real que muestra cómo extender es la creación de una nueva página de administrador con un tentáculo morado. Ya tengo una página de administrador funcionando para mi plugin, pero ni siquiera estoy seguro de si la necesitaré. No está relacionada con los problemas actuales que tengo delante, por lo que su ejemplo no es muy útil para mi caso.

2 Me gusta
18

Los grupos funcionarán bien para ese propósito, y fácilmente puedes tener 200 grupos

En realidad, serían entre 400 y 600 para cubrir todas las permutaciones (propietario, residente o afiliado de cada unidad). ¿Pero cómo funcionaría eso? ¿Pueden 200 grupos mostrarse de forma idéntica a los usuarios, de modo que solo diga “Propietario” en lugar de “Propietario 187” o algo así?

Esta es una pregunta más detallada, pero ¿se expone alguna vez un ID de grupo interno a los usuarios finales, por ejemplo, en una URL? Si un usuario tiene su número de unidad configurado como privado, ¿podría alguien averiguarlo comparando el ID del grupo con otros usuarios?

Me parece que posiblemente obtendría mejores resultados creando solo 3 grupos (propietario, residente y afiliado, o solo 2: propietario y residente). Quizás podría asignar esos grupos según corresponda como dijiste, y luego bloquear ciertas acciones si el usuario intenta moderar a un residente de la unidad incorrecta.

Supongo que si bloquear una acción así es totalmente imposible, entonces sí, estoy atrapado creando 600 grupos… y solo esperando que no tengamos usuarios con ideas ingeniosas para “hackear” el sistema y exponer a nadie.

19

Espera. ¿Qué? Entonces, si soy un inquilino y digo algo en el foro, ¿mi casero puede cambiar mis palabras? Los temas pertenecen solo a una única categoría, por lo que tendrías conversaciones que son solo entre el propietario y el inquilino.

Eso no tiene sentido. Y realmente no hay una manera fácil de tener permisos a nivel de tema.

Pensaría que querrías algunos grupos y categorías por edificio, pero el control por unidad simplemente no tiene sentido.

20

No dije nada sobre permisos a nivel de tema.

¿Quizás “moderador” es la palabra incorrecta? No lo sé. (Nunca antes había usado Discourse).

Estoy hablando de aprobar o eliminar el acceso al foro por usuario. Así que no, tu casero no puede cambiar tus palabras, pero son ellos quienes tienen la autoridad para confirmar tu registro como residente, y si te conviertes en un troll, pueden silenciarte o expulsarte. Las publicaciones y los temas se moderan por igual según una política de contenido, por el personal del sitio web, no por los propietarios.

Mi objetivo es vincular el acceso al foro tanto como sea posible a la cadena legal de autoridad sobre cada propiedad en sí. Ningún propietario confirmado que posea legalmente una propiedad aquí debería ser expulsado, pero si hacen una publicación que viola la política, esa publicación puede ser eliminada por el personal. Sin embargo, si venden la propiedad, su estado de “propietario” se revoca inmediatamente, lo que podría resultar en su eliminación del sitio web (a menos que opten por el estado de “afiliado” y sean aprobados por el nuevo propietario de la propiedad).

En nuestra comunidad no hay ninguna relación entre una unidad y otra en el mismo edificio, excepto que están físicamente unidas. Eso es todo. Agrupar a las personas por edificio es prácticamente una decisión cosmética de experiencia de usuario; nombrar autoridades sobre edificios enteros no tendría sentido aquí.

21

Encontré esto: Add a custom per-user setting in a plugin

En los comentarios, un usuario dijo que “parcheó un controlador”. Tiene un archivo .js.es6 en assets/javascripts/discourse/initializers/ que hace referencia a un método llamado api.modifyClass()…

Hmmm :thinking: Quizás estoy cerca de algo.

2 Me gusta
22

¡Sí! ¡Esa es la clave!

Te aconsejo que te familiarices más con el discurso antes de decidir exactamente qué quieres hacer.

Creo que será más fácil si un pequeño grupo de personas aprueba a quienes se unen al sitio en lugar de que cada propietario de una unidad controle el acceso al sitio. Si los propietarios son quienes deciden, ¿qué sucede cuando alguien vende la unidad? ¿Quién decidiría entonces? ¿Qué pasa con un propietario al que no le importa si su inquilino puede ser miembro del foro? Si creo que dejarlo en manos del administrador del complejo tendría mucho más sentido y probablemente no requeriría un plugin.

1 me gusta