Ahi ahi
Sì, nel nostro caso funzionerebbe. Essenzialmente questo fornisce i livelli di permesso desiderati all’interno di una data Categoria.
Nella maggior parte dei casi sì. Tuttavia, il problema è che si tratta di un permesso a livello di sito. Se ho 5 Categorie e un utente è qualificato per modificare le wiki in una di queste categorie, non dovrebbe essere in grado di modificare le wiki nelle altre quattro categorie.
Quanto spesso gli utenti nella categoria di risposta modificano le wiki? Capisco perfettamente il vantaggio del tuo approccio, ma se qualcuno non è considerato abbastanza qualificato per creare un argomento, non è un rischio quando ha i permessi per modificare l’intero argomento creato? Vedo questo essenzialmente come un backdoor per i permessi.
Nel nostro caso d’uso, l’overhead è in realtà un vantaggio. Assicura che gli utenti non qualificati per modificare la wiki richiedano le loro modifiche come risposta, e il loro desiderio di modifica venga discusso pubblicamente. Fornisce essenzialmente un sistema di revisione tra pari per le modifiche alla wiki.
Nel nostro caso i livelli di fiducia sono stati disabilitati. Quando si utilizza Discourse all’interno di un’azienda, c’è un ulteriore livello di responsabilità da considerare. Un sistema che consente automaticamente a qualcuno di modificare qualcosa oggi, che non poteva modificare ieri, e non è qualificato per modificare, può causare la comparsa di informazioni errate come se fossero ufficiali, inducendo altre persone ad agire su tali informazioni, con conseguenti prodotti difettosi, che si traducono in vittime per i clienti 