The plugin has been updated and tested to be working with Discourse v3.2.1 which is currently the latest stable release (non -beta). We aim at supporting future stable releases only, which means that if you are on a -beta version, chances are that this plugin will not work.
On the GitHub link for the plugin, the readme explains how to be sure to be on v3.2.1.
We have just downgraded from the latest -beta to v3.2.1 and the only issue we have encountered is that the sidebar get a little crazy. To fix it, simply logout and login.
With this update we also included the “change ownership” to the actions available to category moderators as it was requested some time ago.
A Feature request to incorporate these functions is open here. Feel free to support it, if you think it would be useful to include these changes in the core Discourse functionalities.
Features
Since we started using discourse we found the actions available to category moderators to be lacklustre. Most basic content actions are limited (Set slow mode, add staff colour/notice, etc) when there isn’t really a reason in our opinion.
Thus we decided to try our hand and create a plugin that would grant most of the content-related moderation powers to category moderators, when they are in the category they have been assigned to.
These are the only exclusions:
Category Moderators cannot act on users - Suspend, Silence, Change TL, access admin view on users are still reserved to regular moderators
Grant Badges - requires some admin permissions that we preferred not to mess with.
View moderation history - requires some admin permissions that we preferred not to mess with.
Convert Topics to PM and vice versa - We considered this action something of a niche case and preferred to leave this to the regular forum moderators
Configuration
Simply install the plugin as you’ll do for any other and click the checkbox in the settings to turn it on.
CHANGELOG
Initial Beta Release
Updated version working with Discourse v3.2.1
TODO
Detailed settings view that allow to choose which actions to enable for category moderators
You don’t see the reason at all, or for your instance?
We sometimes use it on meta. For example, if a plugin or a theme/component originally developed by someone who doesn’t work on it anymore is transferred to someone else, then we change the author to the new maintainer, or to @system, depending on the context.
Clearly I worded it badly. Fixed now. In the TODO in fact is the possibility to enable that feature as an option.
In our community, that would simply become a wiki post so that everyone can contribute on it. It makes sense in the example you specify but for our forum, the only close case would be a guide for something (self hosting something using raspberry-pi, a guide to a game, a list of events for a band, etc etc)
Here’s an example use case: with the WordPress plugin, users need to be individually configured with a Discourse username — even if SSO ensures they are 1:1. If someone forgets or misconfigures the WordPress side, the post ends up owned by “system”.
Having WordPress moderators be category moderators for the blog comments category would let them take care of this (and, of course, moderate comments).
TL4 are forum wide. In our mind, a category moderator should have access to all tools a moderator has but restricted only by the category itself.
It’s a personal opinion but it really don’t make sense to us that users with an high TL have more power than category moderators when it comes to moderate a category.
TL4 in my opinion are good as they are as they can actually moderate forum wide but not act on users.
They are basically trusted users, recognized by the community to protect and foster it, without the risk of having them go nuts one day on other users account.
Category moderators, again, in our views, should be able to do what a moderator does, but in their own category. This include even banning people but that is on an entire other level of complexity.
What I was thinking is creating a group of users like “banned_from_categoryslug”, that category get assigned with read only to the category and the users added to that.
Alternatively, just extend users using the dedicated table in the db in which you add a user_id, category_id and a datetime. Every time a user access a topic, a check is run to see if he can actually interact with it or not.
The benefit of going for a group-based route is that there is a form of UI already implemented for admins and forum moderators to eventually lift a ban. The other approach would require to also develop a dedicated view but would allow for more flexibility (see ban expirations, etc)
I’m not sure this is a direction that Discourse want to go in, but if category moderators had this kind of power, it would open up the possibility of using categories as forums within a forum. That would be great from my point of view.
I believe Group Owners can remove people from the group, which would then remove their access to the category (if group-restricted). So perhaps a combination of group owner + category moderator would work for this?
Given the statement “these are the only exclusions”, everything on Trust Level Permissions Reference where the Category Moderator column says “TL” or is blank would turn to , except granting badges, changing ownership, and user-account actions.
I’d really love to see this have more granular control — or better yet, for that granular control to be not a plugin but baked in. For me, lack of the ability to change ownership (ironically one of the exclusions, I know), is the big deal — but obviously not for everyone.
실제로 이 방식이 작동합니다. 저는 이 모델을 사용하여 설정을 구성했으며, '게시할 수 없는 경우 메시지 표시’에 대한 HTML/마크다운 토픽에 참여하여 그룹 소유자에게 메시지를 보낼 수 있는 링크가 포함된 메시지를 생성하도록 했습니다.
이 방식은 작동하지만, 더 나은 옵션은 그룹 소유자에게 시간 옵션이 포함된 밴/무음 목록 기능을 추가하는 것입니다. 그러면 문제 사용자를 그룹 접근 카테고리에서 밴할 수 있습니다. 그룹의 가입/탈퇴를 제한 없이 유지하는 옵션도 함께 제공될 수 있습니다. 제한된 그룹에서도 이 목록을 확장하여, 그룹에서 밴된 사용자에게 밴 사유와 함께 알림을 보내는 기능으로 확장할 수 있을 것입니다.
참고@simon도 관심이 있는 것 같으므로, 카테고리 모더레이터를 활용하여 Reddit과 유사한 서브포럼 시스템을 사용할 수 있도록 그룹 기능을 확장하기 위해 Contribute > Feature 요청을 시작할 수 있을 것입니다.
Believe me, I would love that as well from Discourse itself. It’s been incredibly annoying to have someone work on the style of the forum but having to test the changes myself because I couldn’t just give FULL ADMIN to a person that was supposed to work just on css and visuals.
We can look into this. Admittedly something that we simply neglected because we didn’t think of an application (regular forum-wide moderators can do that eventually)
Overall, I would gladly retire this plugin if Discourse implemented a more granular control and would love for category moderator to be able to ban people from their category only, but alas, it doesn’t seem a priority or something they are interested in at this time.
New Revise option for queued posts
Moderators can now select “Revise…” as an option when reviewing posts queued for approval. A PM will be sent to the user with the reason for requesting a revision and optional comments so they have an opportunity to improve their post when they resubmit it.
Did something more than just add a new option because the plugin stopped working. It’s not breaking discourse as far as we can see, but the additional options are not available any more. It’s always fun when someone decide to refactor lots of stuff on top of adding a single new feature
We are trying to look into the code again to figure out what has been changed.
제 이해로는 개발자 중 한 명이나 그들과 가까운 사람이 이것이 우선순위가 아니거나, 그들이 의도하는 방향이 아니라고 말한 것으로 알고 있습니다. 하지만 제가 착각하고 있을 수도 있겠지요. 저는 그냥 지나가는 중인데, 누군가 기능 요청을 열고 싶다면 이 주제를 크로스링크하여 상단 링크에 표시되도록 하거나 저에게 @멘션을 달아주세요. 그러면 첫 번째 게시글을 업데이트하겠습니다.
, except granting badges, changing ownership, and user-account actions.
