Category Moderators Enhancer

Is this big use case here that you want category moderators not to be tl4 ?

I am very open to simply improving core here

8 Likes

I, at least, would like to make a distinction between:

  • recognized by a discussion community as a responsible, productive, constructive participant, and
  • has responsibility and power over a certain area by virtue of role (a role possibly entirely unrelated to general participation in discussion)

TL3 is an automated version of the former, and TL4 seems to me kind of like the “you’ve got tenure!” version of that.

Category moderator is (or should be!) perfect for the latter.

3 Likes

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)

6 Likes

So, what benefits are added?

Moving topics to other categories controlled by the group?
Reviewing flag queue?

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.

4 Likes

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?

3 Likes

Could you please clarify exactly what this changes for Category Moderators. Thank you so much.

Given the statement “these are the only exclusions”, everything on Trust Level Permissions Table (inc Moderator Roles) where the Category Moderator column says “TL” or is blank would turn to :white_check_mark:, 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.

3 Likes

100% agree. :heart:

This can work indeed. I have created a setup using this model and was apart of the html/markdown topic on the Display message if cannot post. To have it generate the message with a link to message group owners.

While this works a better option would be to add a ban\silence list option with time options to group owner. A problem user can then be banned from a group access category. While having an option to keep group unrestricted to join leave. Even in a restricted group this listing could maybe be extended to a notify user has a ban from group with ban note.


Note We could likely start a feature request to extend group functions to enable a reddit like subforum system using category mods… as @simon seems to have an interest as well.

2 Likes

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.

1 Like

I don’t think I can find the feature request for these changes? If you could link to it in the OP it may help get more attention to it?

Might be an idea for me or someone else start the extending groups.

ie

  • Suspend/ban List for Group Owners. Handy in. free to join & Req to join. Would need duration option. This ectension would work to further redditish theme parity.
  • theme with option to restrict theme & /or theme-component

Atm I use req to join groups & template plugin to have a ban list to reference.

Apparently, one of the latest changes

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 :smiley:

We are trying to look into the code again to figure out what has been changed.

1 Like

My understanding was that someone from the devs or close to them said that it wasn’t a priority / direction in which they were intending to go but maybe I am mistaken. I’m just passing by now, if anyone want to open the feature request, feel free to cross-link this topic so it appears in the links at the top or @ me and I will update the first post.

1 Like

You got this from the CEO, so I’d say that was encouraging:

Probably worth a feature request or two if you did want to see them added to core.

Added feature request and link to it in the first post

The recent update that includes new actions for moderators have completely broken our plugin unfortunately.

Even disabling it, it will cause some issues with timer-based moderation actions so the suggested action is to comment out the line in your app.yml file and rebuild until we manage to fix it.

Really sorry for the inconvenience.

2 Likes

Hello :wave:
I wonder if there is any progress on this plugin, I would like to install it on my forum instance?

Unfortunately, with the holidays and previously work related commitments, me and the other guy that are working on this, didn’t have the time to check.

I am going to add that the fact that an update completely changed something under the hood kinda bummed us out, as we had just finished bashing our heads against the code to understand how to implement what we wanted.

There is a feature request open for implementing what we did in the core, maybe give your vote to that as well and write something there.

The best option would be always that these features are implemented into discourse itself rather than a plugin.

The source is open anyway, so if you or someone you know want to help and fix what is not working, PRs are welcome.

2 Likes