Un cliente mi ha contattato con la richiesta di creare una directory utenti basata su schede.
Dato che è ospitato su discourse.org, inizialmente ho detto che non sarebbe stato possibile (a parte eventuali problemi di prestazioni), poiché gli attributi necessari per compilare una scheda utente non sono disponibili nell’oggetto utente serializzato con gli elementi della directory.
Tuttavia, dopo averne discusso ulteriormente, ho determinato che un approccio potrebbe essere quello di creare una PR nel core che aggiunga gli attributi utente al serializzatore degli elementi della directory tramite un’impostazione del sito. L’idea è che questa funzionalità sarà utile per vari stili di directory utenti che richiedono diverse combinazioni di attributi utente (esempio sotto).
Sperimentando con questo, ho elaborato un approccio relativamente semplice, che potete vedere in questa diff:
Creare un DirectoryItemUserSerializer dedicato (l’attuale “UserSerializer” all’interno del DirectoryItemSerializer mi è sempre sembrato un po’ strano).
Se l’amministratore del sito ha selezionato degli attributi utente da aggiungere:
Creare un utente serializzato per sfruttare le protezioni di quel serializzatore, ad esempio attributi per lo staff, privati o non attendibili.
Serializzare gli attributi aggiunti che superano il filtro del UserSerializer.
Gli obiettivi qui sono:
Non influenzare in alcun modo il comportamento esistente.
Serializzare solo gli attributi richiesti.
Se siete d’accordo con questo approccio/richiesta, lo completerò:
Aggiungendo una convalida sull’impostazione del sito (cioè per garantire che la stringa inserita sia un attributo utente)
Aggiungendo i test.
Tuttavia, ho pensato fosse meglio discuterne prima con voi.
Esempio
Come esempio del tipo di funzionalità che questo permetterebbe, lo screenshot qui sotto è dal mio ambiente locale, utilizzando solo questa modifica al core + un componente del tema che sovrascrive la directory esistente e utilizza una componente scheda utente modificata:
Penso che @blake e @awesomerobot stiano lavorando con un altro cliente che ha requisiti simili. Sono abbastanza aperto all’idea di un’impostazione del sito simile a quella che abbiamo per always_include_topic_excerpts.
La riserva è che vorrei che venisse testata e che l’impostazione del sito fosse nascosta.
So che anche @david è interessato al problema; sono un po’ indeciso, ma forse una soluzione più pulita a lungo termine potrebbe essere:
Aggiungere impostazioni del sito nascoste per “consentire a plugin e temi di richiedere informazioni serializzate aggiuntive”, disattivate per impostazione predefinita.
Definire quindi un protocollo nei temi/plugin per “richiedere” le informazioni aggiuntive.
Il vantaggio qui è che alcuni temi avranno le informazioni serializzate aggiuntive, mentre altri no.
Vorrei aspettare un po’ David prima di darti il via libera.
Che ne dici di far sì che il serializzatore della directory degli utenti accetti un nuovo parametro come users.json?include_profile=true?
In questo modo possiamo aggiungere un’API per plugin JS che consenta ai temi di aggiungere questo parametro:
api.userListIncludeProfile(true)
“Profilo” includerebbe tutti gli elementi presenti nel serializzatore utente standard (prestando attenzione a non introdurre query n+1). Non credo che specificare campi individuali abbia un impatto significativo sulle prestazioni, quindi, a mio avviso, dovremmo mantenere la cosa semplice.
Lo stesso approccio potrebbe funzionare anche per le liste degli argomenti, ad esempio ?include_excerpts=true.
Mi piace anche perché significa che la “configurazione del serializzatore per tema” non verrà compromessa dalla cache anonima!
Quasi, ma non funziona in modo pulito perché quando vai alla home page del sito o al percorso u, non hai il lusso di aggiungere un parametro al percorso; dobbiamo cambiare i valori predefiniti
In tal caso, penso che un’impostazione del sito nascosta sia un buon punto di partenza. Sarebbe bello renderla specifica per ogni tema, ma dobbiamo prima costruire un’infrastruttura adeguata. Ritengo comunque che un’impostazione booleana “l’elenco utenti include il profilo” sia più semplice da gestire.
Bene. Fateci sapere se ritenete che questo sia un pr-welcome e in quale forma, e saremo lieti di crearne uno. Da parte nostra, @fzngagan se ne occuperà d’ora in poi.
Una cosa da chiarire qui è il protocollo per richiedere dati aggiuntivi. Possiamo affidarci all’impostazione del sito sul frontend per richiedere i dati o, come hai suggerito, aggiungere un’altra API nel plugin-api?
Manteniamo le cose semplici: ignora il mio post sui parametri e sulle API JavaScript.
Se l’impostazione del sito è abilitata sul server, restituisci le informazioni aggiuntive. Se è disabilitata, non farlo.
Al momento, gli amministratori dovranno abilitare manualmente l’impostazione. In futuro potremmo valutare di permettere ai temi di attivare o disattivare automaticamente questa impostazione.
