Ho impostato una categoria per il tracciamento dei bug sul nostro server Discourse. Vorrei tracciare sia le segnalazioni di bug pubbliche degli utenti sia i bug inviati internamente nello stesso posto.
Voglio che i bug pubblici siano visibili a tutti (quindi gli argomenti privati non sono una soluzione). In questo modo, possiamo ridurre i duplicati e le persone possono commentare o elaborare un argomento esistente.
Voglio anche che i nostri team interni possano inviare bug, ma non voglio che siano visibili al pubblico generale a meno che non lo desideriamo specificamente per un dato argomento.
Possiamo attivare/disattivare ‘Whisper’ sulle risposte, ma non sull’argomento stesso. Quindi c’è un modo per impostare la visibilità per argomento?
Impostare l’argomento su ‘Non in elenco’ fa quasi quello che vogliamo, tranne per il fatto che abbiamo un gruppo di sviluppatori che devono vederli ma non sono impostati come moderatori o amministratori, fanno solo parte di un gruppo.
È possibile avere due versioni di questa gerarchia ad albero? Una per uso interno e una per uso esterno. È possibile utilizzare tag (o tag automatici) per aiutare il team interno a vedere quali bug esistono sia internamente che pubblicamente.
In alternativa, se sei un cliente enterprise, potresti avere abilitate categorie di terzo livello.
Sono self-hosted, quindi posso metterci un altro livello se voglio, ma ancora una volta, non è la soluzione più semplice per l’utente.
Quello che sento è che la mia richiesta non è possibile.
È un peccato. Questo sarebbe risolto avendo un’impostazione del sito per “Consenti a questi gruppi di visualizzare gli argomenti non elencati. Amministratori e moderatori possono sempre visualizzare questi argomenti”.
Quanto è importante per te che altri utenti non leggano questi argomenti?
Dubito che gli argomenti non elencati sarebbero davvero una soluzione per te. Quando segui una categoria, ricevi anche una notifica per ogni argomento non elencato che viene creato. Questa notifica contiene il link, così puoi visitare e leggere l’argomento.
Quindi gli argomenti non sarebbero visibili solo al gruppo specifico.
Solo le categorie controllano l’accesso, ma se vuoi una versione più soft di ciò, potresti fare qualcosa con il CSS per fare qualcosa…
Ah. Forse dovresti cambiare i tuoi permessi in modo che gli sviluppatori (che sono troppo stupidi, pigri o negligenti per mettere le cose nella categoria giusta) non abbiano diritti di creazione nella categoria dei bug pubblici. Quindi, se qualcosa dovesse essere pubblico, qualcuno che ha abbastanza attenzione per essere considerato affidabile può spostarlo nella categoria pubblica.
Questo tipo di soluzione vanifica lo scopo della mia richiesta originale. Voglio una categoria di bug e il controllo sulla visibilità dei singoli argomenti all’interno di quella categoria.
Sembra che dovrebbe essere fattibile, ma in base al feedback, forse no.
Penso che con qualsiasi processo che coinvolga “potrebbe essere pubblico, potrebbe essere privato” ci sarà spazio per errori dell’utente ogni volta che qualcuno crea un argomento. Che si tratti di scegliere la categoria giusta, o di ricordare di fare clic su “sussurra”, o di aggiungere un tag che poi esegue una magia CSS per nasconderlo, e così via. C’è un punto in cui devi fare quella scelta e un’opportunità concomitante per sbagliare.
Penso che una sottocategoria sia la strada da percorrere per poter avere fiducia nelle protezioni di visibilità. Se non vuoi attivare le sotto-sottocategorie per questo (o regolare la struttura della tua categoria di livello superiore con un’alternativa come Category Groups) puoi avere una sottocategoria aggiuntiva in Support per #internal-bug-reports e quindi utilizzare il filtro degli argomenti per creare un elenco di argomenti personalizzato che includa argomenti da entrambe le categorie, che puoi quindi aggiungere alla barra laterale per l’uso dei tuoi sviluppatori.
Per divertimento, ho testato se potevo cambiare il post_type di un OP tramite API. E mentre ha funzionato, è comunque apparso nell’elenco degli argomenti a un utente di test non sussurrante e poi si è verificato un errore quando ci ha cliccato dentro. Quindi sembrerebbe che sarebbe necessario un ulteriore lavoro di sviluppo per smussare questo aspetto (e potrebbero esserci anche altri conflitti per il comportamento inaspettato quando inizi a curiosare).
Potrebbe non essere così male. Non sono sicuro che mi importi se gli utenti normali possono vedere i titoli.
La mia attuale soluzione alternativa è simile:
Crea un argomento con un nome descrittivo appropriato.
Il corpo consisterà in “Tracking bug #”.
Salva
Modifica il post e inserisci il # dall’URL in modo che il corpo ora legga “Tracking bug #138”.
Sussurra tutte le risposte aggiuntive.
Ora aggiungo solo il mio gruppo di sviluppatori ai “Gruppi consentiti per sussurri”.
Non è elegante come vorrei, ma scrivere la SOP per questo è piuttosto semplice.
Questo ha il vantaggio aggiuntivo di consentire a un utente normale di aggiungere un post all’argomento se ha un bug che sembra simile al titolo.
Quindi sembrerebbe che sarebbe necessario un ulteriore lavoro di sviluppo per smussare questo aspetto (e potrebbero esserci anche altri conflitti per il comportamento inaspettato quando inizi a curiosare).