Possible bug in the way SMF handles changing membergroups for a user.

[usaalpine]

alright, I am on a posting spree on SMF matters, and I believe this belongs here vs over in the feature request forum as this exists, and I think it's a problem.

What I am referring to is how SMF handles a user when you change their membergroup(s).

Here is something I noticed about SMF where if a user does not have a "primary" membergroup, the permissions becomes based on "post groups" instead of "membergrops", and that's fine.

My problem is this.

Let's say you have user "X" in membergroup (MG)  "1".

Then for whatever reason, you remove "X" from "1" and you put "X" in MG "2"

At that time, SMF does not make MG "2" user "X's" his primary membergroup, which leads to
permission issues.

You have to remove "X" from MG "2" and then add "X" to MG "2" in order to make that happen.

I haven't had a chance to try the other various combinations of chaning MGs on users, but in either case I don't think this is a good behavior.

Thank you and please advise,

[Dannii]

Which version of SMF? I change members' groups a lot, and I've never seen this problem.

[usaalpine]

I am using 1.1RC2...

When you say you've never seen this problem, perhaps you just haven't seen the affect of it due to your general permission setup.

Whereas in our scenario, I have a lot of the permissions restricted in regards to areas, fetures, PM, member searching, etc..etc..

[Grudge]

Where are you making that change too? SMF doesn't distinguish a users permissions based on whether it is a primary membergroup or not. Primary membergroup only effects the group name displayed under their name.

[usaalpine]

Where are you making that change too? SMF doesn't distinguish a users permissions based on whether it is a primary membergroup or not. Primary membergroup only effects the group name displayed under their name.

I may be using the wrong terminology in regards to how SMF terms things, so let me respond to this real quickly.

SMF may not distinguish permissions based on primary membergroups, however the board behaves differently for a user who doesn't have a primary membersgroup.

Maybe you can chew on that?