$this->ipsclass->vars['banned_group']

[Michael]

When you first set up your IPB, several pre-made groups are created and have their group IDs stored in the conf_global.php file: Guests, Validating, Root Admin, & Members. There are two other groups that get created, but that don't have these static group IDs: Administrator, and Banned. I think that at least for the Banned group, you should also include a row in the conf_global.php file for them, as 'banned_group'. The reason I suggest this is that for mods that get written that want to move members to the Banned group, right now we just have to code in a '5' for the group to move them to and hope that the people using the mod didn't change that. If the Banned group was always available as a var, it would make this method so much easier.

[Logan]

I completely agree.

Brandon and I actually discussed this on AIM, regarding a feature request. The ability to move groups to the banned group when they have reached their full warning capacity for example, and many other uses (especially for modding). I believe he is already considering this.

All other groups have a row in conf_global.php so no reason why the banned group shouldn't.

[princetontiger]

This would be helpful in my ChatRoom product.. definitely... although, it's just the difference between hand editing it, etc.

[Guest]

fusoya can't you add that self in, you're near teh source ;)

but I agree named ids would be best for all predefined groups.

many people find the root admin versus admin also confusing, I'm not sure if that was a good thing to add into (available since 2.1 i believe)

[ellawella]

I've also needed this feature at times.

[Logan]

fusoya can't you add that self in, you're near teh source ;)

but I agree named ids would be best for all predefined groups.

many people find the root admin versus admin also confusing, I'm not sure if that was a good thing to add into (available since 2.1 i believe)

Sure, he or just about any other modder could add this in themselves.

But when they distribute the mod, the user would have to add that row to conf_global.php as well since it wouldn't be a default part of the software and it's really not a good idea for users to be editing the configuration file.

[Guest]

I meant source not as source but as near the IPS guys (as in close contact with brandon & matt) :P

[bfarber]

See, the problem is, the banned group really isn't anything special.

There is banning in IPB based on your IP address, which is different.

The banned group itself simply sets 'Can access board' to 'No'. You could create 100+ banned groups if you want, and none would be anymore special than any other in reality....

It could be added in (for new installs) but it would have little use other than for modding. Unlike guests, root admin, members, and validating - you can actually delete the banned group - leaving the setting in the config file useless (and potentially causing problems later on if a modification wasn't coded to check to see if the group still existed).

It's a tougher issue to tackle than you'd think. Simply because the group has no special qualities requiring this setting.

[Logan]

See, the problem is, the banned group really isn't anything special.

There is banning in IPB based on your IP address, which is different.

The banned group itself simply sets 'Can access board' to 'No'. You could create 100+ banned groups if you want, and none would be anymore special than any other in reality....

It could be added in (for new installs) but it would have little use other than for modding. Unlike guests, root admin, members, and validating - you can actually delete the banned group - leaving the setting in the config file useless (and potentially causing problems later on if a modification wasn't coded to check to see if the group still existed).

It's a tougher issue to tackle than you'd think. Simply because the group has no special qualities requiring this setting.

Why would it only be for new installs?

For the 2.2 upgrade (when it gets to that part of the upgrader) couldn't it check that conf_global.php is CHMOD 777 and then have it automatically insert the line? Then require conf_global.php to be CHMOD back to 644 (infact there is already an alert if conf_global.php is writeable in 2.2) so I think it's safe to require it to be writeable and depend on the user to turn it back to not writeable.

[Antony]

The best thing would be to have a designated user group where, when a users warning reaches 100% the user can be moved to it. Hardcoding a banned group is just annoying becuase not all of us want one. Then you could determine which group that was via the $this->ipsclass->vars['move_to_on_full_warn'] or somthing similar. :)

[Michael]

See, the problem is, the banned group really isn't anything special.

There is banning in IPB based on your IP address, which is different.

The banned group itself simply sets 'Can access board' to 'No'. You could create 100+ banned groups if you want, and none would be anymore special than any other in reality....

It could be added in (for new installs) but it would have little use other than for modding. Unlike guests, root admin, members, and validating - you can actually delete the banned group - leaving the setting in the config file useless (and potentially causing problems later on if a modification wasn't coded to check to see if the group still existed).

It's a tougher issue to tackle than you'd think. Simply because the group has no special qualities requiring this setting.

Yeah, I know all about the different ban options, but I still think it's a common enough practice to just leave the pre-created Banned group on your forum and move members into it. From my experience, you leave the Banned group on your board and put your troublemakers into it, then use the ban filters to prevent them from re-registering. I don't think I've ever seen a board that has more than one Banned group, but then there are a lot of boards out there. It's not really a problem, though, to have 100+ 'Members' groups with slightly different permissions, but just one of them being the members_group.

It would be completely possible to put the same kind of delete protection on that banned_group that the others have. Really, I understand the scope of the problem, but I think it's worth it.

[Antony]

But instead of delete protection, why not just have an AdminCP setting that can be designated as the banned group? That'd be the most sensible way to do it and it'd make everyone happy.