Please remove the ability for super moderators to change a member's group via the warn system.

[grinler]

As the title states, please do not provide the ability for a super moderator to change a member's group via the warn system. This opens too many risks whether they be accidental or intentional. If a user was not given ACP access and the ability to change a member's group, they should not be able to bypass that restriction via the warn system.

Please see this bug topic for more information:

http://community.invisionpower.com/resources/bugs.html/_/ip-board/a-moderator-has-access-to-change-a-user-members-group-when-using-warning-system-r41597

I know someone is going to say if you don't trust them then don't add them as a super moderator. This is not the point. Fine tuned security is important for any multi-user application and having this setting bypasses it. If you wanted a member to people change someones group, then they should be given access to the ACP where they can do it.

I am actually baffled that this made it a live version of IPB.

[Michael]

An administrator can also accidentally change a member's group in the ACP as well. It should not be the software's job to prevent people from doing things accidentally.

[Marcher Technologies]

An administrator can also accidentally change a member's group in the ACP as well. It should not be the software's job to prevent people from doing things accidentally.

look... my whole problem with this is this.

can you as a super-moderator demote an admin to a member with NO acp access?

pre-warnings, no, NOW? yes, if the admin group in question is not protected from the warning system(at default, no groups are) you can go right ahead and make EVERY admin a member, locking ALL out of the ACP: http://screencast.com/t/eJk5M2Jon5qs

group management is traditionally an administration feature, not a front-end moderation one for reasons like this.

And lumping this ability with super-moderator, the single 'all-inclusive' mod option in existence without which many moderation tools vanish because it is used as a crutch to avoid granular control is simply a bad move IMHO.

Frankly, this crosses the line regarding super-moderator, WAY too much power for frontend.

[grinler]

An administrator can also accidentally change a member's group in the ACP as well. It should not be the software's job to prevent people from doing things accidentally.

I am not asking IPB to prevent accidents. I am asking IPB to not give specific permissions to a group that I have not explicitly given them. This opens up holes in multi-user security, which should not exist.

Accidents or otherwise..the simple point is that if I dont give permission, I don't expect them to be able to bypass it.

[GreenLinks]

look... my whole problem with this is this.

can you as a super-moderator demote an admin to a member with NO acp access?

pre-warnings, no, NOW? yes, if the admin group in question is not protected from the warning system(at default, no groups are) you can go right ahead and make EVERY admin a member, locking ALL out of the ACP: http://screencast.com/t/eJk5M2Jon5qs

group management is traditionally an administration feature, not a front-end moderation one for reasons like this.

And lumping this ability with super-moderator, the single 'all-inclusive' mod option in existence without which many moderation tools vanish because it is used as a crutch to avoid granular control is simply a bad move IMHO.

Frankly, this crosses the line regarding super-moderator, WAY too much power for frontend.

Agreed

[media]

Do not get stuck with one word! Accident or permission or something else, this feature should not be there.... :)

[Neil2]

This ability given to global mods is a bug, error, and oversight in the features of the software, there is no other way to describe it and I hope this is repaired, corrected, and fixed in 3.4.4.

[bfarber]

Just to be clear - super moderators (or global moderators) have had complete and total moderator permissions since the beginning of IP.Board. There have traditionally been very, very few settings to control their permissions.

Regarding this original post - prevent admins from being warned via the available setting in the ACP. Issue solved. This setting has been there for quite some time now, and frankly - I can't imagine why you wouldn't configure it like I've just described. I would also prevent super moderators from being warned too, personally.

We are revisiting moderators with IP.Board 4.0 and you may see some changes to how they work at that stage. There will be no changes to how super moderators are handled in 3.4.4.

[grinler]

Brandon, having complete and total moderator permissions is not the same thing as having administrative permissions. This "feature" essentially gives super moderators administrative abilities when they were specifically not given them by an administrator. If I wanted a super moderator to have administrative abilities then I would have made them an Admin. Simple as that. By including a feature like this, IPS is simply bypassing security policies that an admin of the forum has put in place.

On my site, I have all my staff in protected groups and indeed it does solve this problem, but that still does not prevent a super mod accidentally promoting a user to an elevated group.

[Neil2]

Brandon

The warning system is a tool for all website owners, when you allow super mods or even mods to use it which is great for keeping records of issues you have had with members, plus it gives mods without acp access the ability to suspend spammers "which is what I use to for mainly" by the warning system and stop them from posting immediately after they are found.

I personally have admin group protected from the warning system, but you take a new site owner and they turn on the warning system a rouge super mod could pretty much shut out the owner because there is no default protection for the admin group, just like there is no protection for the default admin group in the admin cp which their use to be with the older software.

A new web-site owner is also forced to protect the default admin group by implementing the admin restriction for the new admin group or super mod group if said groups have acp access.

So yes you guys revisiting the moderators ability in the soon upcoming software is great to hear and needs to be done.

[GreenLinks]

I also believe this should be recalled as a bug.

Thing is you may keep that setting over there , however site owner should have freedom to configure his permissions the format he wants. Currently he has to follow the route IPB staff defines and it doesn't give enough flexibility over warning system.

Hopefully this will be rectified and Permission system will have major improvements that allows free configuration options.

[Marcher Technologies]

Groups management->administrative feature.

Warnings->moderation feature.

This topic exists because you mixed the two on the front-end and gave it to super-moderators, the single least controllable option in the suite.

If proper control had been granted, it would be non-issue, but it is lumped with super-moderator.

In Essence, the fine-grain control we have of this with ACP restrictions is not properly represented in the front-end.

This 'feature' is a literal living example for the argument the supermod option as a whole should DIE and be replaced with granular on-off for each power you are giving them.

'Stop' lumping exclusive permissions one cannot enable individually with super-mod... please.... this is just the straw breaks the camels back.

Many options require supmod ability, many options that are less powerful than this, and users are given this power for use of those features.

[S2eve]

I totally agree, I don't want my super-mods to have this ability. Managing users groups its the administrator work. If I'll choose to give this ability to someone, I'll give him acp access with restrictions.

And I agree with Marcher Technologies, you need to give us the ability to choose functions for each group. At my forum I have 3 different groups of moderators, every group has different function, but the set of permissions I give them, is not matching they work. We need more flexibility at those things.

[Maxtor]

i wonder why this bug still is not fixed????? i was forced to disable the entire warning system for this.

[THL]

Yes it looks a messy solution I've got similar issues.