Estendere il controller esistente?

Sviluppatore
1

Ciao a tutti, spero di pubblicare nel posto giusto. Sto cercando di sviluppare un plugin per il mio nuovo sito web Discourse.

Ho fatto un fork del repository di esempio qui, ho fatto funzionare un Plugin Outlet, poi ho colpito un muro e ho iniziato a sentirmi piuttosto perso e confuso. Sto iniziando a prendere confidenza con i framework MVC PHP come Laravel, ma sono MOLTO nuovo ai framework JS. Non ho mai toccato Ruby, Rails o Ember prima d’ora.

Il Problema

Il mio sito web è per una comunità HOA. Quello che sto cercando di fare è raccogliere e salvare alcuni campi dati aggiuntivi per utente:

  • legal_name (stringa)
  • is_owner (booleano)
  • is_resident (booleano)
  • building (stringa) - che rappresenta il numero del loro edificio
  • unit (stringa) - che rappresenta il numero della loro unità
  • … e alcune altre variabili interne, come se un moderatore li ha confermati.

Voglio rendere questi campi obbligatori per la registrazione dell’utente. Ciò significa modificare il modulo di registrazione dell’utente. Mi sono agganciato all’outlet create-account-after-password e ho fatto visualizzare alcuni campi aggiuntivi, ma ovviamente questo non li rende funzionali.

Penso di dover estendere il controller in app/assets/javascripts/discourse/app/controllers/create-account.js, non solo per catturare i nuovi valori del modulo quando vengono inviati, ma anche per qualcosa di (apparentemente) basilare come usare il nome del sito this.siteSettings.title in un campo di traduzione client.en.yml! (Al momento i campi aggiuntivi nel mio modulo di registrazione sono intestati, “Qual è la tua connessione a [valore %{title} mancante]?” Il che ovviamente non va bene.)

Più cercavo risposte, più domande avevo e più diventavano grandi. Diverse guide che ho provato a seguire erano apparentemente scritte per versioni diverse di Discourse. Il repository di esempio del plugin ha cose che non capisco. Qual è la differenza tra una rotta lato client e una rotta lato server? Qual è la differenza tra un plugin e un modulo? Sono così perso.

Se qualcuno potesse offrire un aiuto, sarò molto grato. Grazie in anticipo.

2 Mi Piace
2

Penso che potresti farlo con Creating and configuring custom user fields

3 Mi Piace
3

Grazie! Non fornisce tutte le funzionalità che pensavo di volere, ma mi fa decisamente riflettere se quella funzionalità possa aiutarmi a raggiungere i miei obiettivi.

In ogni caso, penso di dover ancora rispondere alla domanda originale su come estendere i controller esistenti utilizzando un plugin. È possibile una cosa del genere?

4

salvarlo solo per visualizzarlo da qualche parte? cosa vuoi fare con questi dati? ho l’impressione che tu voglia archiviarli per qualche altra funzionalità piuttosto che visualizzarli semplicemente da qualche parte sul forum.

6

Questo può essere realizzato senza alcuna programmazione con Creating and configuring custom user fields

3 Mi Piace
8

cosa vuoi fare con questi dati? ho l’impressione che tu voglia memorizzarli per qualche altra funzionalità piuttosto che visualizzarli semplicemente da qualche parte sul forum.

Beh, la mia speranza/visione finale era:

1. Moderazione a livelli

Concedere ai proprietari di ogni unità nella comunità poteri di moderazione SOLO sui residenti della loro unità.

Tenendo presente che ci sono quasi 200 unità nella nostra comunità, non sembrava fattibile utilizzare la funzione gruppi per raggiungere questo obiettivo. Vedi anche il punto n. 3 di seguito, con cui i gruppi sarebbero in conflitto.

2. Esperienza utente di registrazione

L’esperienza utente perfetta nella mia mente renderebbe anche il menu a discesa per “unità” nel modulo di registrazione reagire dinamicamente alla scelta dell’utente nel campo “edificio”, in modo da offrire solo le unità che si trovano in quell’edificio. (Avrei trovato un modo per analizzare un file di configurazione JSON per questo quando Discourse si inizializzava.)

3. Impostazioni sulla privacy dei campi

Volevo offrire a ciascun utente la scelta se nascondere il proprio edificio e/o numero di unità ad altri utenti non appartenenti alla propria unità.

Ho l’impressione che la funzionalità principale dei campi personalizzati offra questa opzione solo per campo (non per utente) e anche solo agli amministratori, non agli utenti stessi.

4. Stile accattivante

Questa sarebbe più una cosa “ciliegina sulla torta”, ma invece di visualizzarla come qualcosa del tipo “Proprietario: sì”, volevo dare al sistema una conoscenza speciale di questi campi per stilizzarli in modo diverso nei riepiloghi utente. Come inserire un’icona SVG di un atto di proprietà e un segno di spunta se un moderatore ha confermato il loro stato (o un’icona di una casa per i residenti). Quel genere di cose.

Quindi, ecco…

Forse sono troppo esigente qui, ma sento che una volta superata la curva di apprendimento per realizzare la funzionalità principale, gli elementi minori della lista dei desideri diventeranno quasi banali.

Molti dei residenti della mia comunità sono persone anziane con poca o nessuna conoscenza informatica. Ho serie preoccupazioni riguardo ad alcuni residenti che non vogliono adottare e utilizzare il mio sito web Discourse solo perché è nuovo e non Facebook, per non parlare di problemi di utilizzo reali come la privacy degli indirizzi o l’inserimento non convalidato di numeri di edificio/unità.

2 Mi Piace
9

I gruppi funzioneranno bene per questo scopo e puoi facilmente avere 200 gruppi.
Tutto ciò che dovresti fare è mappare manualmente o programmaticamente il campo su un gruppo. Ma potresti anche voler far inviare alle persone una sorta di “prova” dopo la registrazione.
Potresti farlo manualmente, codificarlo da solo, usare il plugin custom wizard di Pavilion per questo.

È vero, ma potresti avere utenti che vogliono renderlo pubblico visualizzando quel campo altrove, cioè avere un campo edificio “privato” e un campo edificio “pubblico”.

2 Mi Piace
10

Se hai bisogno di aggiungere funzionalità, vuoi creare un plugin o un componente del tema, non un fork di Discourse.

Puoi farlo in un componente del tema, quindi non hai bisogno di un plugin per questo, ma se stai creando un plugin, puoi includere anche le modifiche al frontend nel plugin. Developing Discourse Plugins - Part 1 - Create a basic plugin. Cercare plugin che aggiungono funzionalità simili è anche un buon modo per procedere. Esiste un repository di Discourse chiamato all-the-plugins che puoi utilizzare per cercare esempi.

Avere versioni pubbliche o private di quei campi come suggerito sembra una buona soluzione, ma puoi anche aggiungere campi utente in un plugin e controllare come e se quei campi vengono aggiunti al serializzatore per visualizzarli.

Questo è ciò che fanno i componenti del tema. Theme Developer Quick Reference Guide potrebbe essere un inizio.

2 Mi Piace
11

Non credo che TS intendesse fare un fork di discourse??

3 Mi Piace
12

Sembra che il repository che ha collegato sia un fork e non un plugin.

2 Mi Piace
13

image

Fare il fork di discourse-plugin-skeleton sembra un buon inizio per scrivere un plugin per me…

5 Mi Piace
14

Sono d’accordo! Non so cosa penso di aver visto! Non so come mi sia sfuggito che fosse un fork. :person_shrugging:

Pensavo di aver cercato plugin.rb…

2 Mi Piace
15

Va bene, ho imparato cose da questa conversazione :grin:

2 Mi Piace
16

Grazie @RGJ per avermi chiarito! :sweat_smile: Sì, non avrei mai fatto un fork di Discourse solo per questo.

17

puoi anche aggiungere campi utente in un plugin e controllare come e se tali campi vengono aggiunti al serializzatore per visualizzarli.

Ciò include aggiungerli alla finestra modale “crea account” e renderli obbligatori? Puoi indicarmi esempi o guide su come fare?

Ho già letto l’intera guida che hai linkato “Sviluppare plugin per Discourse”. È da lì che ho iniziato. Alla fine, l’unica funzionalità reale che mostra come estendere è la creazione di una nuova pagina di amministrazione con un tentacolo viola. Ho già una pagina di amministrazione funzionante per il mio plugin, ma non sono nemmeno sicuro che mi servirà. È irrilevante per i problemi attuali che ho di fronte, quindi il loro esempio non è molto utile nel mio caso.

2 Mi Piace
18

I gruppi funzioneranno bene per quello scopo e puoi facilmente avere 200 gruppi

In realtà sarebbero tra 400 e 600 per coprire tutte le permutazioni (proprietario, residente o affiliato di ciascuna unità). Ma come funzionerebbe? Possono 200 gruppi visualizzarsi tutti identicamente agli utenti, in modo che dica solo “Proprietario” invece di “Proprietario 187” o qualcosa del genere?

Questa è più una domanda di dettaglio, ma un ID gruppo interno viene esposto agli utenti finali da qualche parte, ad esempio in un URL? Se un utente ha il numero della sua unità impostato su privato, qualcuno potrebbe scoprirlo controllando l’ID gruppo rispetto ad altri utenti?

Mi sembra che potrei ottenere risultati migliori creando solo 3 gruppi (proprietario, residente e affiliato - o solo 2: proprietario e residente). Forse potrei assegnare quei gruppi in modo appropriato come hai detto, quindi bloccare determinate azioni se l’utente sta cercando di moderare un residente dell’unità sbagliata?

Suppongo che se bloccare un’azione del genere è totalmente impossibile, allora sì, sono bloccato con la creazione di 600 gruppi… e spero solo che non ci siano utenti che abbiano idee intelligenti per “hackerare” il sistema e fare doxing a chiunque.

19

Aspetta. Cosa? Quindi se sono un inquilino e dico qualcosa nel forum, il mio padrone di casa può cambiare le mie parole? Gli argomenti sono di proprietà di una singola categoria, quindi avresti conversazioni che sono solo tra il proprietario e l’inquilino.

Non ha senso. E non c’è davvero un modo semplice per avere permessi a livello di argomento.

Penserei che vorresti alcuni gruppi e categorie per edificio, ma il controllo per unità semplicemente non ha senso.

20

Non ho detto nulla riguardo alle autorizzazioni a livello di argomento.

Forse “moderatore” è la parola sbagliata? Non lo so. (Non ho mai usato Discourse prima d’ora.)

Sto parlando di approvare o rimuovere l’accesso al forum per utente. Quindi no, il tuo amministratore non può cambiare le tue parole, ma è lui che ha l’autorità di confermare la tua iscrizione come residente e, se diventi un troll, può silenziarti o bannarti. Post e argomenti sono moderati allo stesso modo rispetto a una politica sui contenuti, dallo staff del sito web, non dai proprietari.

Il mio obiettivo è legare l’accesso al forum il più possibile alla catena legale di autorità su ciascuna proprietà stessa. Nessun proprietario confermato che possiede legalmente una proprietà qui dovrebbe mai essere bannato, ma se pubblica un post che viola la politica, tale post può essere rimosso dallo staff. Tuttavia, se vendono la proprietà, il loro status di “proprietario” viene immediatamente revocato, con possibile rimozione dal sito web (a meno che non optino per lo status di “affiliato” e vengano approvati dal nuovo proprietario della proprietà).

Nella nostra comunità non c’è alcuna relazione tra un’unità e un’altra nello stesso edificio, tranne che sono fisicamente collegate. Questo è tutto. Raggruppare le persone per edificio è praticamente una decisione estetica di UX; nominare autorità su interi edifici non avrebbe senso qui.

21

Ho trovato questo: Add a custom per-user setting in a plugin

Nei commenti, un utente ha detto di aver “patchato un controller”. Ha un file .js.es6 in assets/javascripts/discourse/initializers/ che fa riferimento a un metodo chiamato api.modifyClass()…

Hmmm :thinking: Forse ci sono vicino.

2 Mi Piace
22

Sì! Questo è il biglietto!

Ti consiglio di acquisire maggiore familiarità con il forum prima di decidere cosa fare.

Penso che sarebbe più facile se un piccolo gruppo di persone approvasse l’adesione al sito piuttosto che ogni proprietario di un’unità controllasse anche l’accesso al sito. Se i proprietari sono coloro che decidono, cosa succede quando qualcuno vende l’unità? Chi deciderebbe allora? E un proprietario a cui non importa se il suo inquilino può essere membro del forum? Se penso che lasciare la decisione al gestore del complesso avrebbe molto più senso e probabilmente non richiederebbe un plugin.

1 Mi Piace