Subcategories do not inherit permissions from parent category

(Jakub Ryška) #1

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

Version: 0.9.9.11

(cpradio) #2

This sounds related to

But it looks like you are running the latest version, so it must be different somehow…

Child category seems to inherit part of the permissions in the parent category
(Ying Long) #3

I noticed this too.

Is there a sub category under staff?

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.

(Jakub Ryška) #4

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.

(Kane York) #5

Can you post your category security settings involved?

(Jakub Ryška) #6

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.

(Jakub Ryška) #7

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.

(Kane York) #8

Yes, you will have to redeclare the permissions for every subcategory. There is no inheritance of permissions.

#9

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.

(Joshua Rosenfeld) #10

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.

(Dardub) #11

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.

(Erlend Sogge Heggen) #12

I tend to agree, as I suspect we are deviating from the norm here.

A checkbox for “inherit permissions of parent category” enabled by default would make a lot of sense.

(Matt Palmer) #13

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).

(Shoshana Berleant) #14

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.