Estender Controlador Existente?

Dev
1

Olá a todos, espero estar postando isso no lugar certo. Estou tentando desenvolver um plugin para o meu novo site Discourse.

Eu fiz um fork do repositório de exemplo aqui, consegui fazer um Plugin Outlet funcionar, depois bati em uma parede e comecei a me sentir bastante perdido e confuso. Recentemente, estou começando a pegar o jeito de frameworks MVC PHP como Laravel, mas sou MUITO novo em frameworks JS. Nunca mexi com Ruby, Rails ou Ember antes.

O Problema

Meu site é para uma comunidade de HOA. O que estou tentando fazer é coletar e salvar alguns campos de dados extras por usuário:

  • legal_name (string)
  • is_owner (bool)
  • is_resident (bool)
  • building (string) - representando o número do prédio deles
  • unit (string) - representando o número da unidade deles
  • … e algumas outras variáveis internas, como se um moderador os confirmou.

Quero tornar esses campos obrigatórios para o cadastro de usuários. Isso significa modificar o formulário de cadastro de usuário. Eu me conectei ao outlet create-account-after-password e consegui exibir alguns campos extras, mas obviamente isso não o torna funcional.

Acho que preciso estender o controller em app/assets/javascripts/discourse/app/controllers/create-account.js, não apenas para capturar os novos valores do formulário quando enviados, mas mesmo para algo tão (aparentemente) básico quanto usar o nome do site this.siteSettings.title em um campo de tradução client.en.yml! (No momento, os campos extras no meu formulário de cadastro estão com o título, “Qual é a sua conexão com [valor de %{title} ausente]?” O que obviamente não é bom.)

Quanto mais eu tentava procurar respostas, mais perguntas eu tinha e maiores elas se tornavam. Diferentes guias que tentei seguir foram aparentemente escritos para diferentes versões do Discourse. O repositório de exemplo do plugin tem coisas que não entendo. Qual a diferença entre uma rota do lado do cliente e uma rota do lado do servidor? Qual a diferença entre um plugin e um módulo? Estou tão perdido.

Se alguém puder oferecer alguma ajuda, serei muito grato. Agradeço antecipadamente.

2 curtidas
2

Eu acho que você poderia fazer isso com Creating and configuring custom user fields

3 curtidas
3

Obrigado! Isso não oferece toda a funcionalidade que eu acho que quero, mas definitivamente me faz parar para considerar se esse recurso pode me ajudar a atingir meus objetivos.

De qualquer forma, acho que ainda preciso responder à pergunta original de como estender controladores existentes usando um plugin. Isso é possível?

4

salvar apenas para exibir em algum lugar? o que você quer fazer com esses dados? tenho a impressão de que você quer armazená-los para alguma outra funcionalidade em vez de apenas exibi-los em algum lugar no fórum.

6

Isso pode ser feito sem nenhuma programação com Creating and configuring custom user fields

3 curtidas
8

o que você quer fazer com esses dados? Tenho a impressão de que você quer armazená-los para alguma outra funcionalidade em vez de apenas exibi-los em algum lugar no fórum.

Bem, minha esperança/visão final era:

1. Moderação em camadas

Conceder aos proprietários de cada unidade na comunidade poderes de moderador SOMENTE sobre os moradores de sua unidade.

Tendo em mente que existem quase 200 unidades em nossa comunidade, não parecia viável usar o recurso de grupos para realizar isso. Veja também o item #3 abaixo, com o qual os grupos também entrariam em conflito.

2. Experiência do usuário no cadastro

A experiência do usuário perfeita em minha mente também faria com que o menu suspenso para “unidade” no formulário de cadastro reagisse dinamicamente à escolha do usuário no campo “prédio”, para oferecer apenas unidades que estão naquele prédio. (Eu descobriria alguma maneira de analisar um arquivo de configuração JSON para isso quando o Discourse inicializasse.)

3. Configurações de privacidade de campos

Eu queria oferecer a cada usuário a opção de ocultar seu número de prédio e/ou unidade de outros usuários que não estejam em sua unidade.

Minha impressão é que o recurso principal de campos personalizados oferece essa opção apenas por campo (não por usuário) e também apenas para administradores, não para os próprios usuários.

4. Estilização sofisticada

Isso seria mais um detalhe adicional, mas em vez de exibir como algo como “Proprietário: sim”, eu queria dar ao sistema conhecimento especial desses campos para estilá-los de forma diferente nos resumos de usuários. Como colocar um ícone de escritura SVG e uma marca de seleção se um moderador confirmou seu status (ou um ícone de casa para moradores). Esse tipo de coisa.

Então, é isso…

Talvez eu esteja sendo muito exigente aqui, mas sinto que, uma vez que eu superar a curva de aprendizado para realizar a funcionalidade principal, os itens menores da lista de desejos se tornarão quase triviais.

Muitos dos moradores da minha comunidade são pessoas mais velhas com pouco ou nenhum conhecimento de informática. Tenho sérias preocupações de que alguns dos moradores não queiram adotar e usar meu site Discourse apenas porque é novo e não é o Facebook, quanto mais por causa de problemas de uso genuínos como privacidade de endereço ou entrada não validada de números de prédio/unidade.

2 curtidas
9

Os grupos funcionarão bem para esse propósito, e você pode facilmente ter 200 grupos.
Tudo o que você precisaria fazer é mapear o campo manual ou programaticamente para um grupo. Mas você também pode querer que as pessoas enviem algum tipo de “prova” após o registro.
Você pode fazer isso manualmente, codificar você mesmo, usar o plugin de assistente personalizado do Pavilion para isso.

Isso é verdade, mas você pode ter usuários que desejam exibir publicamente esse campo em outro lugar, ou seja, ter um campo de construção “privado” e um campo de construção “público”.

2 curtidas
10

Se você precisar adicionar recursos, crie um componente de tema, não um fork do Discourse.

Você pode fazer isso em um componente de tema, então não precisa de um plugin para isso, mas se estiver criando um plugin, pode incluir as alterações de front-end no plugin também. Desenvolvendo Plugins do Discourse - Parte 1 - Crie um plugin básico. Procurar por plugins que adicionam funcionalidades semelhantes também é uma boa opção. Existe um repositório do Discourse chamado all-the-plugins que você pode usar para pesquisar exemplos.

Ter versões públicas versus privadas desses campos, como sugerido, parece uma boa solução, mas você também pode adicionar campos de usuário em um plugin e controlar como e se esses campos são adicionados ao serializador para exibi-los.

É para isso que servem os componentes de tema. Guia de Referência Rápida para Desenvolvedores de Temas pode ser um começo.

2 curtidas
11

Eu não acho que o TS pretendia fazer um fork do Discourse??

3 curtidas
12

Parece que o repositório que ele vinculou é um fork e não um plugin.

2 curtidas
13

image

Fazer um fork do discourse-plugin-skeleton parece um bom começo para escrever um plugin para mim…

5 curtidas
14

Concordo! Não sei o que pensei ter visto! Não sei como não percebi que era um fork. :person_shrugging:

Pensei ter procurado por plugin.rb…

2 curtidas
15

Está tudo bem, aprendi coisas com esta conversa como resultado :grin:

2 curtidas
16

Obrigado @RGJ por esclarecer isso para mim! :sweat_smile: Sim, eu definitivamente nunca teria feito um fork do Discourse apenas por isso.

17

você também pode adicionar campos de usuário em um plugin e controlar como e se esses campos são adicionados ao serializador para exibi-los.

Isso inclui adicioná-los ao formulário modal de “criar conta” e torná-los obrigatórios? Você pode me indicar exemplos ou guias sobre como fazer isso?

Eu já li todo o guia que você vinculou “Desenvolvendo Plugins do Discourse”. Foi daí que comecei. No final, a única funcionalidade real que ele mostra como estender é a criação de uma nova página de administrador com um tentáculo roxo. Eu já tenho uma página de administrador funcionando para o meu plugin, mas nem tenho certeza se precisarei de uma. É irrelevante para os problemas atuais que tenho pela frente, então o exemplo deles não é muito útil para o meu caso.

2 curtidas
18

Grupos funcionarão bem para esse propósito, e você pode facilmente ter 200 grupos

Na verdade, seriam entre 400 e 600 para cobrir todas as permutações (proprietário, residente ou afiliado de cada unidade). Mas como isso funcionaria? 200 grupos podem exibir-se de forma idêntica para os usuários, de modo que apenas diga “Proprietário” em vez de “Proprietário 187” ou algo assim?

Esta é uma pergunta mais minuciosa, mas um ID de grupo interno é exposto aos usuários finais em algum lugar, por exemplo, em um URL? Se um usuário tiver o número de sua unidade definido como privado, alguém poderia descobri-lo verificando o ID do grupo em relação a outros usuários?

Parece-me que eu possivelmente teria melhores resultados criando apenas 3 grupos (proprietário, residente e afiliado – ou apenas 2: proprietário e residente). Talvez eu pudesse atribuir esses grupos conforme apropriado, como você disse, e então bloquear certas ações se o usuário estiver tentando moderar um residente da unidade errada?

Suponho que, se bloquear uma ação como essa for totalmente impossível, então sim, estou preso a criar 600 grupos… e apenas esperando que não tenhamos usuários tendo ideias inteligentes para “hackear” o sistema e expor qualquer pessoa.

19

Espere. O quê? Então, se eu for inquilino e disser algo no fórum, meu senhorio poderá mudar minhas palavras? Os tópicos pertencem apenas a uma única categoria, então você teria conversas que seriam apenas entre o proprietário e o inquilino.

Isso não faz sentido. E realmente não há uma maneira fácil de ter permissões em nível de tópico.

Eu pensaria que você gostaria de alguns grupos e categorias por prédio, mas o controle por unidade simplesmente não faz sentido.

20

Eu não disse nada sobre permissões em nível de tópico.

Talvez “moderador” seja a palavra errada? Não sei. (Nunca usei o Discourse antes.)

Estou falando sobre aprovar ou remover o acesso ao fórum por usuário. Então não, seu senhorio não pode mudar suas palavras, mas ele é quem tem autoridade para confirmar sua inscrição como residente e, se você se tornar um troll, ele pode silenciar ou banir você. Posts e tópicos são moderados igualmente contra uma política de conteúdo, por funcionários do site, não pelos proprietários.

Meu objetivo é vincular o acesso ao fórum o máximo possível à cadeia legal de autoridade sobre cada propriedade. Nenhum proprietário confirmado que possui legalmente uma propriedade aqui deve ser banido, mas se ele fizer uma postagem que viole a política, essa postagem pode ser removida pela equipe. No entanto, se ele vender a propriedade, seu status de “proprietário” é imediatamente revogado, possivelmente resultando na remoção do site (a menos que ele opte pelo status de “afiliado” e seja aprovado pelo novo proprietário da propriedade).

Em nossa comunidade, não há relação entre uma unidade e outra no mesmo prédio, exceto que ela está fisicamente anexada. É só isso. Agrupar pessoas por prédio é praticamente uma decisão cosmética de UX; nomear autoridades sobre prédios inteiros não faria sentido aqui.

21

Encontrei isto: Add a custom per-user setting in a plugin

Nos comentários, um utilizador disse que “corrigiu um controlador”. Ele tem um ficheiro .js.es6 em assets/javascripts/discourse/initializers/ que referencia um método chamado api.modifyClass() …

Hmmm :thinking: Talvez eu esteja a chegar a algo aqui.

2 curtidas
22

Sim! É isso aí!

Eu aconselho que você se familiarize mais com o discourse antes de decidir exatamente o que quer fazer.

Acho que será mais fácil se um pequeno grupo de pessoas aprovar quem entra no site do que cada proprietário de uma unidade controlar o acesso ao site. Se os proprietários são quem decide, o que acontece quando alguém vende a unidade? Quem decidiria então? E quanto a um proprietário que não se importa se seu inquilino pode ser membro do fórum? Se acho que deixar para o gerente do complexo faria muito mais sentido e provavelmente não exigiria um plugin.

1 curtida