Vorrei nascondere gli argomenti nella pagina “Latest” (Più recenti) agli utenti che sono membri di un certo gruppo “cattivo”. Credo che questo possa essere fatto con un componente del tema, ma sono aperto a suggerimenti. Questo è un caso d’uso unico e non ho bisogno di un’interfaccia utente per modificare i parametri.
Ecco uno sforzo simile, forse un punto di partenza. L’approccio consiste nell’utilizzare api.modifyClass per aggiungere una classe agli argomenti (i <tr> nella pagina “Latest”), quindi alcune righe di CSS per impostare quella classe su display: none. Presumo che si possa ottenere l’utente in modifyClass e aggiungere la classe se l’utente è membro del gruppo “cattivo”.
(Mi rendo conto che questo non influisce sui loro permessi, possono ancora vedere l’argomento nella vista Categorie o Ricerca, riceveranno ancora email, potrebbero scoprire il mio trucco e modificare il loro CSS locale, ecc. Voglio solo creare un fastidio e indurli ad agire. Date tutte le restrizioni, penso che questo approccio funzionerà.)
Quando ne hai bisogno?
Nelle prossime settimane.
Qual è il tuo budget, in dollari USA, che puoi offrire per questo compito?
Vuoi che /latest sia vuoto per questi utenti? O nascondere solo alcuni argomenti?
Lo scopo è infastidirli? (perché infastidiscono tutti?). Mi chiedo solo se ci sia un modo migliore per infastidirli.
Ho dimenticato di menzionare, vogliamo ancora permettere loro di vedere un argomento nella loro sezione “Latest”: i Termini di Servizio aggiornati.
Non mi piace molto nemmeno a me, ma è il meglio a cui riesco a pensare. L’obiettivo è far firmare a tutti gli utenti i ToS aggiornati, con un’importanza superiore al solito. C’è stata una discussione su How to force existing users to accept ToS sul fatto che forse Discourse Policy potrebbe aiutare. Ma Policy non impone nulla, e data l’importanza dei nuovi ToS vogliamo qualcosa di più di una bolla blu per sollecitare gli utenti. Abbiamo sviluppato un plugin qualche anno fa per aggiungere membri a un gruppo quando accettavano una policy, e ha funzionato per alcune cose, ma non riesco a capire come farlo funzionare per questo.
Abbiamo già un set di gruppi e categorie piuttosto elaborato, quindi non possiamo semplicemente cambiare i permessi su ogni categoria da “tutti” a “tos-acceptors”. Se i permessi delle categorie supportassero la logica booleana, forse potremmo cambiare i permessi per consentire solo agli utenti che sono membri sia di “premium-group” che di “tos-acceptors”. Ma non lo supporta.
Non ho un’opinione forte su come sollecitarli. Se ci fosse un qualche tipo di applicazione integrata di Discourse Policy, la userei. Ma in questo caso abbiamo bisogno di più di una bolla blu.
Ho anche considerato brevemente di reindirizzarli con un permalink se non sono membri di tos-acceptors. Questa è ancora un’opzione se potessimo aggiungere l’ID utente o il nome utente all’URL del permalink come parametri di query. Se li reindirizziamo a Docusign o qualcosa di simile, potrei impostare un webhook per aggiungerli al gruppo “tos-acceptors” in modo che smettano di essere reindirizzati. Ti sembra un piano migliore?
Forse dai un’occhiata a uno dei componenti "Gate" esistenti e regola i loro criteri? Questi hanno dei blocchi piuttosto fastidiosi e informano gli utenti su ciò che è previsto in modo chiaro e diretto.
C’è sicuramente spazio per impostare condizioni basate sull’appartenenza a un gruppo e per modificare l’appartenenza a un gruppo dall’output della procedura guidata.
Un plugin che consentirebbe un’impostazione di permesso complesso per le categorie sarebbe utile in molte situazioni. Questo potrebbe essere il modo migliore per dedicare tempo allo sviluppo per quel problema?
Forse con una formula slug in un’impostazione di testo:
ad es.: (#tos-acceptor o #direct-concern) e #premium-group