Adding membergroups as board moderators

[Oldiesmann]

One feature I've always wanted to see in SMF, particularly with the moderation and membergroup enhancements that came with 2.0, is the ability to assign an entire membergroup to moderate a board. Currently you can accomplish a similar thing by giving a group moderator-like permissions on a board and then assigning members to that group, but this could be a bit confusion as the regular users wouldn't really know that the members in that group could moderate those boards (although this partly depends on how the admin chooses to publicize things and the group names).

The membergroups-as-moderators feature would let you choose membergroups which would also be listed as moderators alongside the regular members. When a user clicked on the group name, they would be taken to the page which showed the members in that group, and (depending on settings), allowed them to join/request to join that group.

The one thing I can't decide on is how to handle permissions.  Should the members in those groups be treated the same as regular board moderators (same permissions, being listed as a "Moderator" rather than a member of whatever their primary group is, etc.), or should it be more of an aesthetic thing (basically just adding the option to specify that the group should be listed as a moderator for that board)?

I'm inclined to go with the first option, as it makes things a bit less confusing (ideally, all members assigned to moderate a board should have the same permissions, regardless of whether they're assigned individually or as part of a group assigned to moderate the board), but I'm thinking this might confuse some people, as doing it this way would prevent you from being able to edit permissions specifically for that group for those particular boards (eg the permissions for those groups would be inherited from the main "Moderators" group).

Let me know which option you feel is best

[Radick]

I would defiantly like a function like that!
I have some communities and i hate it to manage every user for every board an i can't use easily a usergroup...

[Hoodie]

This is definitely something I'd be interested in.  The way I do it now is setting up profiles to be used with board permissions.  It doesn't publicly display them as moderators which is fine with me because their title kind of already gives that impression.

I run a site for an iOS game and there are many clans on my forum.  Each new clan means a new profile as well so it kind of sucks.  If I could assing a membergroup to be moderator for that forum and that forum only though, that would be awesome.

[RoadRash]

I would love this.

For my point of view, it should behave exactly the same as  if the user was added to the list of moderators directly - ideally in the board overview the names of the users and not the group is listed. So it would be just a more convinient option to add multiple users :-)

[emanuele]

* emanuele would love to see a mod (or a PR) at some point.

[SD-X]

I would love to see membergroups have both this option, and the option to moderate other membergroups too. Both methods are much more secure on large forums where users can constantly lose and gain ranks, because all permissions would thus be inherited via the assigned rank, rather than that plus board moderator rights plus membergroup moderator rights, all of which need removal when someone loses a rank that is relative to said rights.

[Oldiesmann]

Since there still seems to be some interest in this, the basic consensus is that a group assigned to moderate a board should inherit permissions from the "moderators" group on that board, correct?

Once I figure out how to do that, it shouldn't be all that difficult to add this functionality.

I'm not sure about the idea of having groups moderating other groups. That gets a bit more complicated and could easily be abused.

[Arantor]

It should. Essentially in loadBoard, figure out what groups there are that are moderators, then whether the current user is in any of those groups, and if so, add group 3 to their account (just like it currently does if they're a board moderator)

[Oldiesmann]

Good point Arantor. I hadn't thought of that for some reason

I'll look into this more in the coming weeks as I have more time and see what I can come up with

[SD-X]

Since there still seems to be some interest in this, the basic consensus is that a group assigned to moderate a board should inherit permissions from the "moderators" group on that board, correct?

Once I figure out how to do that, it shouldn't be all that difficult to add this functionality.

I'm not sure about the idea of having groups moderating other groups. That gets a bit more complicated and could easily be abused.

About membergroups as Board Moderators:
I believe so, yes. Although board profiles can make this happen permissions-wise already, having the ability to have membergroups as Board Moderators also opens up other possibilities that are currently being discussed elsewhere, and can be useful to forums where Administrators also don't know how to use board profiles. It is also a nice visual for forums that wish to make the Board Moderators known to their users by membergroup.

About membergroups moderating membergroups:
Nearly every other forum software out there now has the ability to set groups to moderate other groups. I actually don't understand why that wasn't set up that way from the start with SMF. Many online forums have lower "ranks" within groups that they need the upper ones to keep control of. Allowing them to moderate each other provides for a much more secure way to do this, as it's one less place a user needs to have their rights set and removed from. Otherwise, like in the current version of SMF, Administrators must remember to set a user to both the membergroup and the membergroup moderation by username. Allowing membergroups to moderate other membergroups saves them the trouble on forums where it is useful. One less thing to have to remember, from which permissions can keep control of, is better in this case. If an Administrator forgets to remove both rights, you get a possible security breach from removed users. I've even seen it abused many times before too. Most Administrators expect it to be as easy as setting the user and being done with it.

[Arantor]

I'd love to know where you're getting this 'many online forums have...' bit. The reality doesn't seem to agree, in that normally moderators can issue warnings to anyone and that if you have too many groups it's going to get chaotic whatever you do.

Also, just because 'nearly every other software out there...' has a feature does not mean the feature is implicitly a good idea.

[SD-X]

I'd love to know where you're getting this 'many online forums have...' bit. The reality doesn't seem to agree, in that normally moderators can issue warnings to anyone and that if you have too many groups it's going to get chaotic whatever you do.

Also, just because 'nearly every other software out there...' has a feature does not mean the feature is implicitly a good idea.

I wasn't referring to the warning system at all in this topic.

[Kindred]

and also, this discussion is about making a group that is the moderators of a single board...   this is separate form the requesto to make groups to be the moderators of other groups.

[Arantor]

Correct... but if you can 'moderate' another group, that would generally imply warning them when they misbehave. Anything else is straight up permissions and requires additional, largely unnecessary complexity.

[Oldiesmann]

One quick update for those who are interested in this...

I am all but done coding and testing this, and I've been extremely thorough adding this.

Current features:
Ability to add groups as moderators from the Manage Boards area
Moderator groups are shown in the list of moderators in the linktree on messageindex and display
Users can click on a group name in that list to see who's in that group
Users in a group assigned to moderate a board will automatically inherit any additional permissions from the "Moderators" group on that board
Users in a group assigned to moderate a board will be shown as moderators in the posts in those boards
Moderator groups are listed in the "Boards" report in the admin center
The "Staff" report in the admin center lists users who are in groups assigned to moderate boards, with the appropriate boards which that user can moderate
The "Track Permissions" feature in the user's profile shows any permissions inherited from the "Moderator" group

The only issue left that I want to fix is that the "Board Permissions" report in the admin center does not reflect permissions inherited from the Moderator group

[SD-X]

One quick update for those who are interested in this...

I am all but done coding and testing this, and I've been extremely thorough adding this.

Current features:
Ability to add groups as moderators from the Manage Boards area
Moderator groups are shown in the list of moderators in the linktree on messageindex and display
Users can click on a group name in that list to see who's in that group
Users in a group assigned to moderate a board will automatically inherit any additional permissions from the "Moderators" group on that board
Users in a group assigned to moderate a board will be shown as moderators in the posts in those boards
Moderator groups are listed in the "Boards" report in the admin center
The "Staff" report in the admin center lists users who are in groups assigned to moderate boards, with the appropriate boards which that user can moderate
The "Track Permissions" feature in the user's profile shows any permissions inherited from the "Moderator" group

The only issue left that I want to fix is that the "Board Permissions" report in the admin center does not reflect permissions inherited from the Moderator group

Very nice! Keep up the awesome work!

[Oldiesmann]

Got it figured out and working properly. I also modified the help text for the moderator group in the admin center to say that permissions assigned to that group will also apply to any group assigned to moderate a board.

For those interested in seeing the changes involved, the pull request can be viewed at https://github.com/SimpleMachines/SMF2.1/pull/318.

[Hoodie]

Looking good Oldiesmann.  I haven't been on the email tied to this account in a while and didn't notice all the discussion this has brought up.   Glad to see the interest for it was there and very happy to see progress being made on the mod.  Can't wait to see it.

[Oldiesmann]

Looking good Oldiesmann.  I haven't been on the email tied to this account in a while and didn't notice all the discussion this has brought up.   Glad to see the interest for it was there and very happy to see progress being made on the mod.  Can't wait to see it.

Just to clear up the confusion, as of right now this has been submitted as a possibility for a new feature in SMF 2.1 (and, given emanuele's comment above, I don't have much doubt that this will eventually make its way to SMF 2.1).

Due to the enormous amount of changes involved with this, I'm a bit hesitant to release it as a mod, but I will see what I can do.

[emanuele]

If you read also my comment elsewhere I'm not at all keen on adding anything else to 2.1: the more you add, the more is likely to fail something, somewhere and so a longer testing period is needed.

My comment above was more "create a mod so it can be used with 2.1, then a PR so it can be in 2.2".

[Oldiesmann]

If we were at the RC stage (or even late in the beta stages), I'd agree with you about not breaking stuff, but we're in the alpha stage. We can afford to possibly break stuff, and this really improves the usefulness of SMF - especially on larger forums.

[emanuele]

The point is always the same: we are not even in beta because no one is working on what would be needed to finish and release a beta (and yes, I'm not working on that because I have no theming skills whatsoever, and I repeated that several times), but in the last months several people submitted several features.

Well, do you want features?
Let's add them.
Do you want to release something?
Get someone to work on what is needed.

I have my pets too and I would love to see them in 2.1, but I refrained from adding anything too big (yes, I expanded the admin search to all the admin pages and that required a bi of reorganization, but it is a feature improvement, and I merged the banEdit rework, but it's a re-work and cleanup, nothing new) in the hope to be able to release something in the "close" future (and for those that may read this, to me "close" means not before the end of the year for an RC at that level and I'm being optimist here).

But, as I said don't know where: do you want to release what we have now as beta?
It's not up to the par to be a beta IMHO, but if you think it's okay go ahead, to me it's perfectly fine.

[Oldiesmann]

The point is always the same: we are not even in beta because no one is working on what would be needed to finish and release a beta (and yes, I'm not working on that because I have no theming skills whatsoever, and I repeated that several times), but in the last months several people submitted several features.

Well, do you want features?
Let's add them.
Do you want to release something?
Get someone to work on what is needed.

I have my pets too and I would love to see them in 2.1, but I refrained from adding anything too big (yes, I expanded the admin search to all the admin pages and that required a bi of reorganization, but it is a feature improvement, and I merged the banEdit rework, but it's a re-work and cleanup, nothing new) in the hope to be able to release something in the "close" future (and for those that may read this, to me "close" means not before the end of the year for an RC at that level and I'm being optimist here).

But, as I said don't know where: do you want to release what we have now as beta?
It's not up to the par to be a beta IMHO, but if you think it's okay go ahead, to me it's perfectly fine.

I never said or even suggested that we should release the current version as a beta. I have no idea what even needs to be done before a beta release at this point (but if it's theme-related, I can't help there either). I do realize that we'll never get anywhere if we ignore existing issues and spend all our time adding new features instead. That being said, we also can't keep pushing features back to 2.2 just because it's not what needs to be done for beta and/or we don't want to break something. What's more important here - possibly breaking something before the beta (and beta periods are designed to find and fix bugs/broken features), or adding a major feature which greatly improves the usability and user-friendliness of SMF?

[IchBin™]

What's more important, adding more code to the base so that it takes longer to get the SMF2.1 final, or to leave it alone and add it for the next version? This argument has been said many, many times by many people on the team. This is why you guys need a lead dev.

[Arantor]

What's more important, adding more code to the base so that it takes longer to get the SMF2.1 final, or to leave it alone and add it for the next version?

What's more important, doing something or doing nothing while hoping someone else will do it? This is the real problem at hand.


Here's the thing, this has been done. It's implemented. It's on Github. Include it already and move on with the next thing. Arguing about whether you're going to add something already working and considered 'quite important' just kills what little motivation there is left to do anything.

[IchBin™]

Not if you're putting these features in a repo for 2.2. Doesn't kill motivation if you know it's going to be in the next release. But to continue to pile into the list of things that everyone thinks SMF2.1 needs is just going to extend the process. History proves that already.

[Arantor]

I'd agree with you, if this wasn't already implemented and presumably working. As it stands, you have a feature that works, is considered quite important. The actual implementation looks - at a glance - like it should do the job.

The problem with your assertion is that history doesn't actually back you up. Yes, there are features in 1.1/2.0/2.1 that not everyone needs. That's the nature of the beast, and yes, continuing to pile in features can be problematic - if there's no-one interested, willing and capable of reviewing those features and accepting the pull requests into the trunk.

It isn't about the ever-moving goalposts, it's about the lack of people willing and capable of getting the ball into the goal. And it is this sort of argument that pushes those people away. History DOES prove that.

[IchBin™]

The history of SMF2 proves it. How much crap kept getting added, and how many goal posts were moved? It too far longer to get SMF2 stable because of this. Sure there was other stuff, but a big part of the reason it took SMF2 so long was because of all the crap that kept getting added. Even in the RC's. I'm not denying that part of what you're saying is true. The fact of the matter is, it was already agreed upon what was going to be in the next release. And now here they are doing it again as they have always done in the past. Either way, no skin of my back. This will just push it out even further until they find someone capable and willing to stick to a plan and finish the next release.

[Chalky]

I know that my lack of coding skills and knowledge of the inner workings of SMF is such that I feel I have no right to even be posting here, but it is in the public board and I'm an SMF user, so what the hell... I have to say I agree with Arantor.  This isn't somebody saying "hey I've got a cool idea for a feature for 2.1", this is somebody saying "here's the code - it's done, it works, it's ready for action".  Why not include it in 2.1?  It would certainly save a helluva lot of time arguing about it, and nobody really knows what the future holds for 2.2 or how many new funky features it's going to need just to keep it current.  This feature is here, now and there's time to get it in there before the beta release.  I say go for it.

[Arantor]

I was going to post a rebuttal to the whole 'feature frozen' thing, citing when things were mentioned as such, when it was declared as such and how many years after it took to getting released - and of course, total turnover of dev team, multiple times, had absolutely nothing to do with it, but then I realised even by my standards it was petty.

What amuses me is that this is a team member making this suggestion. Were it a community member, I would not be even remotely surprised, but a team member. This from the same team that has multiple members who have told me that dev team members are not special compared to any other team members. If that's so, any team member contribution is equivalent to a dev team member doing so... and thus there is even less argument that actually stands up to this not being included.