Ik heb een categorie ingesteld voor het volgen van bugs op onze Discourse-server. Ik wil zowel openbare bugmeldingen van gebruikers als intern ingediende bugs op dezelfde plaats volgen.
Ik wil dat openbare bugs door iedereen bekeken kunnen worden (dus privéonderwerpen zijn geen oplossing). Op deze manier kunnen we duplicaten verminderen en kunnen mensen commentaar geven of uitweiden over een bestaand onderwerp.
Ik wil ook dat onze interne teams bugs kunnen indienen, maar ik wil niet dat deze zichtbaar zijn voor het grote publiek, tenzij we dat specifiek willen voor een bepaald onderwerp.
We kunnen Whisper inschakelen voor antwoorden, maar niet voor het onderwerp zelf. Dus is er een manier om de zichtbaarheid per onderwerp in te stellen?
Het instellen van het onderwerp op ‘Onvermeld’ doet bijna wat we willen, behalve dat we een groep ontwikkelaars hebben die ze moeten zien, maar die niet zijn ingesteld als mods of beheerders, ze zitten gewoon in een groep.
Kunt u twee versies van deze boomhiërarchie hebben? Eén voor intern en één voor extern. U kunt tags (of auto-tags) gebruiken om het interne team te helpen zien welke bugs zowel intern als publiekelijk bestaan.
Als alternatief, als u een zakelijke klant bent, kunt u categorieën van het derde niveau ingeschakeld hebben.
Ik ben zelf gehost, dus ik kan er nog een niveau in stoppen als ik dat wil, maar nogmaals, het is niet de meest eenvoudige oplossing voor de gebruiker.
Wat ik hoor, is dat mijn verzoek niet mogelijk is.
Dat is jammer. Dit zou worden opgelost door een site-instelling te hebben voor “Sta deze groepen toe om Onvermelde Onderwerpen te bekijken. Admins en Mods kunnen deze onderwerpen altijd bekijken.”
Hoe belangrijk is het voor u dat andere gebruikers deze onderwerpen niet lezen?
Ik betwijfel of niet-vermelde onderwerpen echt een oplossing voor u zouden zijn. Wanneer u een categorie bekijkt, ontvangt u ook een melding voor elk niet-vermeld onderwerp dat wordt aangemaakt. Deze melding bevat de link, zodat u het onderwerp kunt bezoeken en lezen.
De onderwerpen zouden dus niet alleen zichtbaar zijn voor de specifieke groep.
Only categories control access, but if you want a soft version of that , you could do something with CSS to do something . . .
Ah. Maybe what you should do is change your permissions so that developers (who are to stupid, lazy, or careless to put things in the right category) do not have create rights in the public bug category. Then if something should be public, someone who has enough attention span to be trusted can move them to the public category.
That sort of defeats the purpose of my original request. I want one bugs category and control over the visibility of individual topics within that category.
Seems like it should be doable, but based on feedback, maybe not.
I think with any process that involves ‘could be public, could be private’ there’s going to be scope for user error every time someone creates a topic. Whether it’s picking the right category, or remembering to click ‘whisper’, or adding a tag that then does some CSS magic to hide it, and so on. There’s a point where you have to make that choice and an accompanying opportunity to mess it up.
I think a subcategory is the way to go to be able to have confidence in the visibility protections. If you don’t want to toggle on sub-subcategories for this (or adjust your top level category structure with an alternative like Category Groups) you can have an extra subcategory in Support for #internal-bug-reports and then use the topic filter to create a custom topic list including topics from both categories, which you can then add to the sidebar for your devs to use.
Just for fun, I tested whether I could flip the post_type of an OP using the API. And while it did work, it still appeared in the topic list to a non-whisper test user and then errors out when they click into it. So it seems there would need to be some additional dev work to smooth that out (and there may also be other conflicts for the unexpected behaviour too when you start poking around)
[quote=“JammyDodger, post:12, topic:373766”]
En hoewel het werkte, verscheen het nog steeds in de topiclijst voor een niet-fluister testgebruiker en gaf het daarna een foutmelding wanneer ze erop klikten.
[/quote]Dat is misschien niet zo erg. Ik weet niet zeker of het me kan schelen of gewone gebruikers de titels kunnen zien.
Mijn huidige oplossing is vergelijkbaar:
Maak een topic aan met een goed beschrijvende naam.
De inhoud zal bestaan uit “Tracking bug #”.
Opslaan
Bewerk het bericht en voeg het # uit de URL toe, zodat de inhoud nu luidt “Tracking bug #138”.
Fluister alle aanvullende reacties.
Nu voeg ik gewoon mijn dev-groep toe aan de ‘Toegestane fluistergroepen’.
Niet zo elegant als ik zou willen, maar het uitschrijven van de SOP ervoor is vrij eenvoudig.
Dit heeft het toegevoegde voordeel dat een gewone gebruiker een bericht aan het topic kan toevoegen als ze een bug hebben die lijkt op de titel.
So it seems there would need to be some additional dev work to smooth that out (and there may also be other conflicts for the unexpected behaviour too when you start poking around)