This is what we get when we try to create a subcat for admins (same problem for mods) within the Staff category:
“Any group that is allowed to access a subcategory must also be allowed to access the parent category. The following groups have access to one of the subcategories, but no access to parent category: admins.”
But:
moderators do have access to the Staff category, as do admins. So we should be able to do so.
I admin another forum that has existed for several years, where we have subcats under Staff that are just for admins or just for mods.
Thoughts?
[EDIT: just for fun I screenshot the actual lable that shows up when you try to do an admin-only category:
It’s kind of funny because (a) admin do have access to the Staff subcat, but also (b) admins can go anywhere… So by default they have access to any category.
And, of course, you cannot edit the security section of Staff to add specifically mods and admins to the overall category. ]
You need to make sure that the subcategories that you create are available only to staff. You tried to create one that was available to everyone, but you didn’t notice the permissions when you did, so you don’t think this is true.
That’s what I thought hence my deleted message, but read again the error message:
“Any group that is allowed to access a subcategory must also be allowed to access the parent category. The following groups have access to one of the subcategories, but no access to parent category: moderators.”
So I tried and encountered the same issue.
I try to create a subcategory with security set as “moderators: can see/post/create”, but I have the same error message though moderators are supposed to be included in “staff” and the parent category security is set as “staff: can read/post/create”.
I think what happens is because security is set by groups, not by capabilities.
A moderator belongs to both staff and moderator groups.
But if there was a staff category and a moderators subcategory, what would happen for someone only belonging to the moderator group? He could access the subcategory but not the parent category and Discourse doesn’t allow that.
In theory, if you wanted to have a subcategory accessible by moderators, you would have added “moderators: can see/post/create” to the parent category security, but it’s not possible on the default staff subcategory.
And also, it would be pointless since staff means moderator and administrator, and administrators have access to all categories.
yes. But that is what we did. We removed the everyone permission etc… and only left, either admin or mods, as the group that could access the subcat. But it does not work.
Although it used to be possible. And, based on permissions rules, it should be possible.
I think it might be.
There are issues that only admins can read about due to privacy and other issues. So we need admin-only subcats.
The mod subcats are for convenience: containing discussions about mod topics in one specific area. Since admins can see everything anyway, we could label them for mods but have them for staff, and that would work. It would solve that half of the problem, although, of course, only by cheating.
But the other half we can’t solve. I will edit the original post to reflect admins.
That is the incorrect. Mods can access the Staff category. So having a mods (or an admins) subcat is (or should be) allowed by Discourse. The rule is that any group that can access a subcat must also be able to access the category.
But it would not be pointless at all to have an admin-only subcat, since mods do not get to see all that admins do.
Read more carefully my message: as the system is made, it is working the proper way and the error you encountered is normal. The forum accessibility only relies on groups.
The default staff category, automatically created by discourse, is only available for the Staff group.
If you want to create a subcategory for the Moderators group, it won’t work because the parent category is only available for the Staff group, not Moderators group.
The only reason moderators have access to the parent category is because they also belong to the Staff group.
You can still create a subcategory named “moderation” and set the security as “staff can read/post/reply”, it will work.
Yes it would and you can make a category or subcategory only available for the Administrators group without any issue.
To be clear: I think this is indeed the reason for the problem. I originally had thought to mention that as an explanation but decided to post without…
But, in that case, this is one of those insidious bugs where the rules you devise do not reflect the reasons that created them. It is very clear that mods are a part of staff, as are admins, and that reason would want them to be able to have subcats within Staff.
And, in fact, a couple of years ago, it was possible to create subcats in Staff just for admins or “just” for mods: this was clearly proper.
Why would it be pointless to have a subcat for only admins?
Not in the Staff category. Look at the screeenshot above.
Yes you are right.
If you want to create these subcategories, you should create a news staff parent category with the security set Administrators, Staff, Moderators can read/post/create" I guess.
Why not just create a New Category as mentioned? Staff is a specialized group.
I can add users to several groups. Just because a some users belongs to Group B and might also be apart of Group A. Doesn’t mean that Group A access to a Category automatically Qualifies group B to have access. Trust Level Category Permissions however work at a minimal level.
I dunno but imagine you can likely edit Staff Permissions to allow Moderator group direct access.
There’s no such thing as hierarchical permissions within Discourse. Staff is a special collection of admins+moderators. Subcategories can’t specify groups which aren’t present on the parent category, and the Staff Group has fixed ACLs. As noted on the staff category:
Warning: This category is a pre-seeded category and the security settings cannot be edited. If you do not wish to use this category, delete it instead of repurposing it.
This isn’t a bug, you just have a use-case which doesn’t suit the default staff category. There’s nothing wrong with wanting to do something different, but it would be wrong to insist that because you can’t use a built-in category for a different purpose that this was somehow a bug.
It’s pretty clear you don’t want to use it as-is. There’s nothing stopping you creating a new parent category accessible to administrators and moderators, then separate subcategories for each below it.
This is an extremely minor bug with the category permission warning system, because it doesn’t know that staff == admins + moderators.
Not worth 12 posts of back-and-forth arguing.
You can work around this by adding admins and moderators explicitly to the parent category as allowed groups. Keep in mind that admins will still have access to the moderators subcategory.
Yes. But the mods won’t have access to the admin subcategories.
Yes in the general case, but that is not possible in the Staff category which is auto-created and where privileges cannot be changed, which was the topic of the question. Since (a) the Staff category is auto-populated in every install, (b) it is important for usability reasons to limit the number of categories, and ( c) the Staff category used to work properly, I don’t look at this as an unreasonable request.
My suggestion is a simple solution. Right now, when auto-creating the Staff category, the following permissions are set up (and it is not possible to modify them):
staff can create/reply/see
Instead, when auto-creating Staff, Discourse should have the following permissions set up:
staff can create/reply/see
admins can create/reply/see
moderators can create/reply see
With this simple fix, this bug would be resolved, we wouldn’t need to create additional and useless categories, and the Staff category would work as it used to in the past.
I think your points are backwards, creating a purpose-built category for your purposes is vastly simpler than changing a built-in category, particularly when thousands of other installations already operate with the existing permissions.
Actually, if you read my solution carefully, you will realize that it is backward compatible, and keeps the previous installations working as they had before.
But it has nothing to do with backwards compatibility. In this topic you’re the only person pushing for a change. What you’re proposing still requires development time, still requires testing and still requires maintaining. Thousands of installations working with the existing config means there are also thousands of admin/moderation teams who don’t mind the as-is setting.
This topic is months old. You could have implemented the correct way to do this back in April, why would you expect CDCK to finance a change to their software, something which has worked this way for seven years, for a single site? Why should anyone do anything if you’re unwilling to make the simplest change to your own configuration? Your unwilling to follow guidance doesn’t encourage action by anyone else.
There’s nothing special about the staff category, as suggested months ago you could create a different category with the appropriate permissions. Problem solved.
It’s vastly simpler for your to implement a small change on your community, than any of the above.
It is not the correct way to do it—but I did implement it in April. We don’t normally wait for bugs to get fixed or features to get implemented in order to get our stuff in order.
Yes, yes, and no. I spent many years as a software developer and manager, and I am well aware of what it takes to fix a bug. This fix would take a few minutes of development time, a few hours of testing time, and no more maintenance than the present version does now.
Your argument means that there is absolutely no point in developing anything new, then. There are thousands of teams using Discourse as it is—why spend even one more hour developing? Let’s use logic when we argue, please.
This was a uselessly rude assumption, which is obviously groundless given my comments above.
Actually, you are wrong. It worked differently, and better, for a long time. Here is an example of an existing, hosted Discourse system, that is 4-5 years old, with a native staff category that allows mod subcats:
The point has nothing to do with my system. I don’t need the change to make it work. The point is that every single Discourse system comes with a Staff category that is inferior in capabilities to what it could be, and what it was. If Discourse goes through the trouble of auto-creating a Staff category, why not engineer it well and cleanly? I am making a suggestion that is simple and easy to implement, and that will regain capabilities that are useful to those of us who deal with multiple categories of staff. The team is free to consider my suggestion—or not.
Warning: This category is a pre-seeded category and the security settings cannot be edited. If you do not wish to use this category, delete it instead of repurposing it.
Just recreate the staff category and move the topics to the new one?
