Let’s say I have Category A and to participate, you have to be a member of Group A. We also have Category B, which is a sub-category of Category A. To participate, you have to be a member of Group B.
What I expected:
To view Category A, you have to be a member of Group A.
To view Category B, you have to be a member of Group B.
Reality:
To view Category A, you have to be a member of Group A.
To view Category B, you have to be a member of Group A and Group B. (this was a “gotcha” for me)
I understand the nested relationship of categories implies the nested permissions, but this isn’t explicit in the category dialogue. I have users who are members of Group B but cannot see Category B. Now, however, what I’ll need to do is to move Category B out from under Category A so that I can apply the proper permissions. While this isn’t too big of a deal, it’s diminishes the utility of hierarchical categories for me and is going to lead to a lot of additional clutter on the Category page.
Is that the desired cascading permission behavior? Should that be explicit in the Category setup page?
Following your assumptions in the first paragraph, if Category B is a sub-category of Cateogry A, and you must be a member of Group A to see Category A, why would you expect to see something within Category A if you are not a part of Group A?
Yeah, I understand the logic there. It depends on how you view categories. In my primary use case, at my company, we have hundreds of categories for various projects. We end up using nesting of categories more to organize things into sensical domains. Here’s the (sanitized) specific use case where it came to mind:
Category A is for the Widget Department. The Widget Department has a small team that meets to discuss some sensitive affairs. There’s a nested category under the Widget Department category called Sensitive Widget Affairs. Our company hired an ombudsman who needs to see stuff in Sensitive Widget Affairs, but does not need to see everything in the general Widget Department category.
Now we’re a little stuck: our options are to move Sensitive Widget Affairs out from underneath the Widget Department Category or make the ombudsman a member of the group that can view everything in the general Widget Department category.
Yeah, that’s a good idea. We grew organically and ended up with the current structure.
I think it’s worth making the point that one of the reasons we’re paying close attention to some of these issues is that one of the top complaints we get about Discourse, from new users in the organization, is that there’s too much stuff and they can’t figure out how to find the topics and categories that are of most interest to them. In another thread (no idea which…) I mentioned that I thought that the ability to have “favorite” categories and/or more of an opt-in system for content would help alleviate this problem. It could be that we simply keep bumping up against edge case issues since we’re trying to use it as a very broad communication/collaboration platform instead of as a more domain-focused discussion forum type tool.