I have set up a category for bug tracking on our Discourse server. I’d like to track both public bug submissions from users and internally submitted bugs in the same place.
I want public bugs to be viewable by everyone (so private topics isn’t a solution). This way, we can cut down on duplicates, and folks can comment or elaborate on an existing topic.
I also want our internal teams to be able to submit bugs, but I don’t want them viewable by the general public unless we specifically want that for a given topic.
We can toggle Whisper on replies, but not on the topic itself. So is there a way to set per topic viewability?
Setting the topic to ‘Unlisted’ almost does what we want, except that we have a group of developers that need to see them but are not set to mods or admins, they’re just in a group.
Can you have two versions of this tree hierarchy? One for internal and one for external. You can use tags (or auto-tags) to help the internal team see what bugs exist both internally and publicly.
Alternately, if you’re an enterprise customer, you could have third-level categories enabled.
I’m self hosted, so I can put another level in there if I want it, but again, it’s not the most simple solution for the user.
What I’m hearing is that my request isn’t possible.
That’s a bummer. This would be solved by having a site setting for “Allow these groups to view Unlisted Topics. Admins and Mods can always view these topics.”
How important is it to you that other users don’t read these topics?
I doubt that unlisted topics would really be a solution for you. When you watch a category you also get a notification for every unlisted topic that is created. This notification contains the link so you can visit and read the topic.
So the topics would not only be visible to the specific group.
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)
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)