# Subcategories do not inherit permissions from parent category

**URL:** <https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174>\
**Category:** Feature\
**Created:** [Juillet 3, 2014, 6:41 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174 "2014-07-03T18:41:49Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![Christopher\_Batcheld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/christopher_batcheld/32/140747_2.png) [@Christopher\_Batcheld](https://meta.discourse.org/u/Christopher_Batcheld)\
**Post date:** [Novembre 29, 2018, 5:40 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/21 "2018-11-29T05:40:26Z")

</div>

> [@sam](#):
>
> 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.

A very good point. And good to hear “out loud”. This is the right way for me to be thinking about confidentiality and privacy.

---

<div class="post-metadata">

**Author:** ![hellekin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/hellekin/32/51636_2.png) [@hellekin](https://meta.discourse.org/u/hellekin)\
**Post date:** [Février 10, 2019, 10:10 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/22 "2019-02-10T10:10:09Z")

</div>

> [@Discourse Version 2.3](https://meta.discourse.org/t/discourse-version-2-3/96690/1):
>
> Do not allow saving a category if child permissions are **LESS** restrictive than parent: [Subcategories do not inherit permissions from parent category](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/20) @maja

I have used private categories with “less private” subcategories, so that a group can work in their space and publish things to a larger public. I guess this line of work will become obsolete by this change. So I should let users know that when they want to publish something, they need to move it to another, more public category. But then, how do they find their common work on this? I suppose they need to maintain a “publications” topic where they link the ‘more public’ topics. Any thoughts?

---

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [Février 14, 2019, 5:24 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/23 "2019-02-14T05:24:42Z")

</div>

I am reviewing [FIX: validate parent category/subcategories permissions by majakomel · Pull Request #6877 · discourse/discourse · GitHub](https://github.com/discourse/discourse/pull/6877) by @maja.

The particular condition we are protecting against is:

```plaintext
- category (authors: read)
- subcategory (pilots: read)

```

What this means is that `pilots` are not allowed to see anything in the `category` yet have been granted permissions in the `subcategory` so something is fishy 🐟

The condition:

```plaintext
- category (authors: read)
- subcategory (pilots: read, authors: write)

```

Is still 🆗 after this new validation.

The tricky thing though 🦙 is that we no longer will allow:

```plaintext
- category (trust_level_3: read)
- subcategory (trust_level_4: write)

```

This particular edge case gives me pause, there is an easy enough work around … you would have to explicitly change

```plaintext
- category (trust_level_3: read, trust_level_4: read)

```

Given the OP is in a pretty bad state I say we see how the new restriction shakes up. FYI @HAWK @jomaxro

---

<div class="post-metadata">

**Author:** ![kkershaw](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/kkershaw/32/115025_2.png) [@kkershaw](https://meta.discourse.org/u/kkershaw)\
**Post date:** [Août 14, 2019, 7:41 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/26 "2019-08-14T19:41:48Z")

</div>

@sam Je vois que la PR a été fusionnée, mais je ne suis pas sûr que la fonctionnalité d’héritage soit prise en compte dans notre installation de Discourse `v2.4.0.beta2 +183` ?

Nous avons été assez choqués de réaliser que tout le contenu que nous pensions privé dans les sous-catégories était instantanément accessible au public non authentifié via `latest`.

Comme nous avons presque 10 catégories, chacune avec de nombreuses sous-catégories, il serait vraiment fastidieux de devoir configurer manuellement les permissions pour chacune d’elles.

---

<div class="post-metadata">

**Author:** ![Alex\_P](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/alex_p/32/163548_2.png) [@Alex\_P](https://meta.discourse.org/u/Alex_P)\
**Post date:** [Février 16, 2020, 2:03 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/27 "2020-02-16T14:03:02Z")

</div>

@sam Cela semble fonctionner maintenant, mais il semble qu’il reste un cas limite (qui nous a un peu posé problème aujourd’hui ☹ ).

Il est possible de supprimer toutes les autorisations dans l’onglet Sécurité lors de la création de la sous-catégorie, et dans ce cas, la sous-catégorie (par exemple, de la catégorie personnel) sera créée avec succès et visible par tout le monde.

---

<div class="post-metadata">

**Author:** ![shayan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/shayan/32/208027_2.png) [@shayan](https://meta.discourse.org/u/shayan)\
**Post date:** [Novembre 29, 2021, 5:39 UTC](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174/28 "2021-11-29T17:39:23Z")

</div>

Pour faire suite, je voulais savoir si cette option a été activée quelque part ? Un moyen de modifier la permission des catégories et que toutes les sous-catégories héritent de cette nouvelle permission ?

[Page précédente](https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174.md?page=1)
