This is looks as a very severe bug, so apologies if someone already posted it, but I don’t know how to search for it. Here it goes:
The bug
Given I’m user who is not in the group staff,
When I go to the main listing of topics - / root of the discourse,
Then I see even the topics, that should be hidden to me, because I don’t have read privileges for them.
Also, in the listing, I can see the topic title, but the topic category is hidden.
When I click on the topic, that should be hidden, only header will remain, with the rest of the page blank with this error in console:
Uncaught TypeError: Cannot read property '__ember_meta__' of undefined vendor-0cf7f8ddcf2bd3b5854f3b875e88d515.js:6
In my case, If I set the parent category AAA’s permission as ‘admin can read’ for example, but set sub category BBB’s permission as ‘everyone can read’, then everyone can see the topic title posted in BBB. And when click that topic, will see a blank page.
The difference is that in my case, the user is authenticated, but apart from that, it is the same, the super category has permission - only staff can read, yet it can be seen on the listing by non-staff users.
Yes, in my case it is the same. By staff I meant the discourse group. staff has access to topic AAA, whereas others don’t have, but the others still can see the topic’s titles in the listings.
The supercategory has setting, that only staff group can read/write, but the subcategory has permission, that anybody can read/write, which kind of doesn’t make sense if the subcategory inherits the permission scheme from the supercategory. Does it?
I set this configuration with the following steps and thoughts: I set up the permissions supercategory, and then removed all permissions from the subcategory, thinking that the subcategory will inherit it, but it looks like that the subcategory gets assigned anybody rights if I save there the permissions with no rights at all.
I’d like to resurface this feature request. At the very least, there should be a warning during subcategory creation that permissions of the parent are different and not inherited.
If subcategories are going to inherit permissions, it needs to be optional! A quick example off the top of my head would be an “archive” type subcategory, where typical users can read, but not start new topics, where the category it is a part of has “everyone” permissions.
Why can’t permissions be inherited by default, with the option to override/change on the sub-category? This is troublesome when admins create sub-categories on a Staff category and inadvertently due to lack of knowledge or forgetfulness, don’t set the permissions.
I’ll add myself to the set of people for whom inheriting permissions from the parent category would be the least surprising behaviour. It’s also the safer option, because it fails closed (users can’t see subcategory they expected to see), rather than failing open (users can see subcategory they… really shouldn’t).
An update for anyone who stumbles on this thread in the future, like me. The posters above said that the contents of the posts appeared to be more restricted than their titles. That is no longer the case–clicking the topic titles doesn’t result in an error.
This still appears to be a thing and bit a number of our clients in the bum. Is this a planned feature or do we have to instruct to be super-duper careful to set the same permissions as the parent category each time they add a new Subcategory?
I think the ideal thing to add some sort of safety net when you change parent permissions to ensure there is no case where and child subcategory is less restrictive than parent. Add that same safety net when saving a child category.
The worst case is when you can not access a parent but have access to a child. Stuff simply does not work right.
I think simply raising errors for now when you try to save in such conditions is the best path forward.
Eg:
Parent:
Staff: read
Child:
Team: read
(click save on child)
Users in child category will not have access to parent category, save is not allowed!
This would be killer. On this client we’re creating Groups for each cohort of the program they are running. If they accidentally forget to assign the group to the subcategories, topics are broadcast publicly. Not only would this save lots of time having to assign groups to each category, it’d get rid of the potential for accidentally leaking content for private groups.
I completely agree and add my support to this feature. We are also working with learning groups and teams from different organizations and the risks are potentially high. I’ve actually thought perhaps we should be using separate Discourse installations to keep this from happening. Would love to see this feature implemented for all the reasons listed above by others. Many thanks to those who are working on this!
Keep in mind, if the risks are high I strongly recommend running a second instance, we do so as well and have our internal, for the company only, discussions in a private instance. It provides a significantly higher barrier and internal company memos don’t accidentally find themselves on meta this way.
No matter what we do to clean up category permissions the vector of “user picking wrong category… disaster” is not something any UX can completely eliminate.
The category permission stuff re inheritance is definitely something we will fix though. At a minimum not allow any cases to save where child is less restrictive than parent.
