Tuttavia, ci sono casi d’uso per grandi community come la mia in cui abbiamo letteralmente forum più piccoli esistenti all’interno di quello principale. Pensate ai Clan nella cultura dei videogiochi.
Queste sottocommunity adottano le regole principali della bacheca, ma poi hanno anche alcune regole aggiuntive specifiche e un team dedicato che ha il compito di moderare la sezione, oltre a guidarla, ma questo è un dettaglio secondario.
I moderatori di categoria non possono agire sugli Utenti stessi, solo sulla categoria, tuttavia dovrebbero, nel mio caso d’uso, essere in grado di impedire ad alcuni utenti di partecipare se infrangono alcune delle loro regole del sotto-forum.
Tutto ciò di cui ho veramente bisogno è sapere se ci potrebbe essere abbastanza granularità nelle funzioni principali per consentire ai moderatori di categoria di bloccare utenti specifici dall’accesso alla loro categoria.
Il modo in cui posso immaginarlo è che venga generata una tabella personalizzata che aggiunge sia category_id che user_id e quando un utente tenta di accedere a un argomento o categoria specifica, semplicemente controlla anche quella tabella.
Sono fuori strada? Sarebbe fattibile? Ho molta esperienza nello sviluppo software ma quasi nulla con Ruby, quindi non so davvero dove iniziare a cercare nel codice sorgente di Discourse per capire dove dovrei guardare
Potresti consentire solo ai membri della categoria del clan di pubblicare e rimuovere gli utenti che non desideri nella categoria. Ciò richiederebbe che tutti coloro che desideri nella categoria siano membri di quel gruppo.
Ho fatto lo stesso. E poiché non permetto a nessuno di salire automaticamente oltre il TL2, è stata una soluzione mentalmente e amministrativamente molto facile e semplice. C’era anche un pizzico di eleganza
L’ho fatto per un cliente un po’ di tempo fa. I livelli di fiducia non funzionavano per noi, quindi invece abbiamo creato gruppi privati per categoria in cui ogni utente veniva automaticamente provisionato, e i moderatori di categoria ne erano i proprietari.
I “ban” erano semplici come rimuovere tali appartenenze, il che significava zero lavoro da parte dell’amministrazione.
Leggermente più sforzo per iniziare, ma effettivamente zero in seguito.
Esempio: uno dei miei clienti ha un forum con una categoria “In vendita”, accessibile da TL2 in su.
Vogliono vietare a determinati membri di creare argomenti lì, ma dovrebbero copiare e mantenere un gruppo che contenga le stesse persone di TL2 meno 5 utenti specifici.
Presumibilmente lo stesso modo, fornire agli utenti gruppi basati su un criterio (rilevare la promozione a TL2?) quindi rimuoverli se necessario? Solo perché TL2 è il criterio di ingresso non significa che sia necessario fare affidamento su quello stato TL2 per determinare l’appartenenza, vero? Dipende anche dal tempo e dalle risorse che si hanno per ingegnerizzare qualcosa sulla propria istanza.
Non ho suggerito che fosse una soluzione unica per tutti. Potrebbe non funzionare per il loro caso d’uso se non vogliono fare il lavoro extra, ma per l’esempio con il mio cliente e lo scenario in cui un’istanza viene partizionata in gilda/clan/qualunque cosa possa essere una buona soluzione.
Ma se stiamo comunque ingegnerizzando qualcosa sull’istanza, allora preferirei avere la funzionalità di ban per categoria
Rende anche le cose più manutenibili. Se ho 50.000 utenti e ho bisogno che tutti possano accedere alla categoria tranne alcuni, allora è difficile ottenere un elenco di questi pochi.
Voglio dire, il ban è solo un’altra parola per esclusione, e Discourse non ha davvero un permesso di esclusione. Ha bisogno di esistere quando “non inclusione” è effettivamente la stessa cosa? Mi piace il modello di permesso esplicito, rende la risoluzione dei problemi indolore.
Ho ancora qualche incubo occasionale riguardo al tentativo di risolvere il modello permesso/negato di vBulletin tanti anni fa. L’unica cosa che ho sperimentato con più dolore e debito associati è RSOP.
Apprezzo tutti gli spunti per soluzioni alternative, ma ho posto una domanda tecnica specifica, non alternative che rappresentano compromessi rispetto a ciò che sto cercando di capire
@crius sarebbe fattibile con un plugin, penso che si possa arrivare abbastanza lontano sul lato client sovrascrivendo i permissions nel serializzatore della categoria, e sul lato server aggiungendo un controllo aggiuntivo utilizzando NewPostManager.add_handler.
Hai considerato l’uso dei gruppi? Crea una categoria con 2 gruppi per l’accesso. 1 Gruppo sono i tuoi moderatori di categoria. L’altro sono i tuoi partecipanti al sotto-forum. Al gruppo dei partecipanti è richiesto di richiedere l’accesso all’area del sotto-forum. I tuoi moderatori di categoria, in tutto o in parte, sono i proprietari di quel gruppo. Se un membro viola le regole che richiedono di espellerlo dal sotto-forum. Espellilo dal gruppo dei partecipanti e comunica con gli altri moderatori di categoria sulla durata.
Bene, allora sfortunatamente potresti dover prendere in considerazione la sponsorizzazione di un plugin. Questo è un ottimo concetto per il crowdfunding di plugin. Il team principale potrebbe eventualmente aggiungere qualcosa di simile a quello che stai chiedendo, ma potrebbe volerci del tempo a causa delle priorità nella lista di sviluppo.
D’altra parte, con il suggerimento di gruppo, potrebbe essere possibile aggiungere un’opzione di espulsione dal gruppo con un componente del tema.
Sei assolutamente sicuro di aver posto la domanda giusta
Intendo dire che il tuo obiettivo principale è risolvere un problema e il ban di categoria è solo la tua risposta irrisolta a questo. La domanda giusta sarebbe come risolvo il problema X e quali sono le mie opzioni.
Ho valutato la possibilità di gestire questo con TL o gruppi di utenti, ma aumenterà il carico di lavoro dei moderatori, il che semplicemente non è fattibile nelle grandi community.
I gruppi di utenti, in particolare, sono dannosi per un’esperienza utente snella.
Non ho bisogno di chiedere una sponsorizzazione poiché ho molta esperienza come ingegnere del software e altre persone che hanno molta esperienza. Semplicemente non usiamo Ruby, quindi questo sarà l’unico rallentamento.
Grazie comunque per gli spunti. Apprezzo che questo forum tenda ad essere molto schietto, ma quando si tratta del software stesso, sarebbe meglio semplicemente seguire un approccio più “dare l’opzione” con, ovviamente, una complessità aggiuntiva a livello di codice che si trova dall’altra parte della bilancia.
Tanto amore a @RGJ per aver aggiunto qualche spunto
