Child category seems to inherit part of the permissions in the parent category

Repro steps

  • set a parent category with permission to create/reply/see to a specific trust level (I set it to 2)
  • set a child category with permission to create/reply/see to everyone


  • Topics created in the parent category will not be visible to users of trust level below 2 (correct)
  • Topics created in the child category will be visible to all in the topic list (correct) but the category name will not be shown on the topic list, if the user is not at level 2 or above (incorrect) and users at the lower level of 2 will not be able to open topic in the child category because the category name will not appear in the dropdown menu (incorrect)

Since there is no inheritance between parent and child, the child category should behave as a separate category, regardless of parent category settings.

User at TL2:

User at TL1:

TL1 user can still reply and see, but cannot create new topics in the child category

I can repro even on (I created a subcategory of Staff - Everyone can see this category? - with permissions to everyone can see/reply/create and then open this topic


Yeah, I don’t know if this is documented, but the child categories must have a permission equal or more restrictive than their parents, otherwise stuff get’s strange.

In special when you can’t even see the parent, but can post to the children the UI get’s buggy.


I found only very old topics but the bugs reported below have already been fixed

1 Like

Our use-case depends on this functionality. According to other threads this should be perfectly possible (e.g. . Subcategories do not inherit permissions from parent category) If it’s not do-able or the bugs are severe, we will need to rethink some things :confused: How bad is it?

Child permissions cannot be less restrictive than the parent category clarification: per @riking the parent category must have at least “see” permissions because it is illegal in the mathematical sense, and leads to some divide-by-zero type scenarios.

1 Like

That is incorrect - the only restriction is that all users with access to subcategories must also have See permission on the parent category, as you need to know that the parent category exists in order to name the subcategories correctly.

So the fix for @Dax’s issue in the OP is to give everyone: See to the parent, as everyone: C/R/S is applied to the subcategory.


It seems to work anyway, as tested on my local discourse installation and other people in the thread I linked to above. Is that a bug? Everyone in that thread thought that the permissions of category/subcategories were entirely independent (and the app certainly behaves that way). I think this means that the correct documentation needs to be easier to find and that the “see” permissions of child categories needs to be enforced upon category creation/update. What do you think?