I'd like to suggest when adding default usergroups during the MyBB 1.8 installation that the usergroup ID's be more organized. For example, when populating the database with usergroups, it could show up like:
1 = Banned
2 = Guests
3 = Awaiting Activation
4 = Registered Users
5 = Moderators
6 = Super Moderators
7 = Administrators
OR
1 = Administrators
2 = Super Moderators
3 = Moderators
4 = Registered Users
5 = Awaiting Activation
6 = Guests
7 = Banned
Keeping the default groups in a orderly manner instead of being randomly added. This could make remembering the default IDs easier to remember for those who wish to customize the core or develop plugins specific for certain groups.
If re-ordering the Group ID assignments is out of the question, then I would also like to suggest that removing group configuration options, such as whether the options of a group being public or not showing up in the ACP, be handled through the database. If someone were to change the IDs for each group to how they want it to appear, they don't have to change the core code (and lose any changes if there are updates for the file). So let's say someone wanted to reorganize the IDs to how they wanted it, they wouldn't need to find each instance of "$gid == 1" in the core files and change the integer to whatever the new one is. Let's also say "showOptionsPublic" would handle whether or not to show the "Is Public Group?" option and anything options related to public groups, they could just change the setting in the database from 0 to 1 or vice versa, essentially removing the dependency of "$gid == int" so they don't have to edit the core.
If the second suggestion were under consideration, would it hurt performance or not effect performance?
I kind of agree on the fact that they should be re-ordered to the second option you have listed. It not only makes more sense logically but as you said would be easier to remember IDs who to specifically customize a plugin to act on certain IDs without having to check what groups what users are in, etc.
This is unnecessary. In most cases only those with access to the Admin CP will see these numbers. Furthermore it would over complicate the upgrade process, in addition several parts of the package (and some plugins might) depend on the fact that moderators have the gid of 5.
The IDs are set, it's pointless changing them it's like saying that I don't like this thread ID can we change it from 154056 to 154050 (or similar).
In my opinion I can't see any realistic reason why this will improve the software (apart from being extremely picky about something that is hard to change). In the context of discussions on a forum: will a user really be snooping around trying to find out if the group IDs are not in a logical order? I think not.
Since this also involves group ids, I think the package and plugins should instead use if($mybb->usergroup['canmodcp']) instead of checking a usergroup id since that actually verifies the person is a moderator. It also means a person can freely edit the group "Moderators" to be exactly how they want to be or could even get rid of it entirely.
While I can understand why this might be desired, I think there's way too much work here for something that has very little actual gain at the present time.
Like JordanMussi mentioned, upgrading would be problematic since the upgrade process would have to be rewritten to include a section to redo all the GIDs, check for permissions and errors. So that you don't suddenly end up in a case where the guest group is the one with ACP access and you're "locked" out.
Plus the Merge script would have to be rewritten to account for this also. Or else it would risk the same situation with the upgrade process.
And then plugin developers would have to be check their plugins to make sure they didn't require GIDs. (And some of the plugin developers aren't active anymore or take a fire and forget approach to their plugins. So if things break, you may have to fix them yourself.)
I mean it's not that difficult to check what the GIDs are for each group. (Just go to the User & Groups section, click into the group's page from the left menu, hover over the group and look at the url that shows up. The last number, where it says "gid=" is the number you want.)
And, again like pointed out, the only ones who really need to know what the GIDs are can already check.
(2014-05-24, 10:40 AM)JordanMussi Wrote: [ -> ]This is unnecessary. In most cases only those with access to the Admin CP will see these numbers. Furthermore it would over complicate the upgrade process, in addition several parts of the package (and some plugins might) depend on the fact that moderators have the gid of 5.
The IDs are set, it's pointless changing them it's like saying that I don't like this thread ID can we change it from 154056 to 154050 (or similar).
In my opinion I can't see any realistic reason why this will improve the software (apart from being extremely picky about something that is hard to change). In the context of discussions on a forum: will a user really be snooping around trying to find out if the group IDs are not in a logical order? I think not.
JordanMussi, you never mentioned anything about the latter suggestion about removing the dependence of GID checks, one of which removes some settings from the ACP view.
Such as when an Admin views the usergroup "Awaiting Activation" the settings in the ACP don't even show up. In 1.6 this is handled by group id checks. I think it would be better if options were removed from view through the settings in database table usergroups.
So instead of "if ($gid ==
int)" it would be "if($mybb->usergroup['showSpecificSettings'])" so people who do want to change the group ID, won't have to worry about changing the core as well.
I agree that reordering the default groups in existing forums would be a major pain, and is completely unnecessary. For new installations, I like the first ordering (from least permissions to most), but this would be a convenience and not a necessity.
Group IDs should NOT be hard-coded in the core (nor in plugins); permissions should be checked instead. I don't think the groups page in the ACP even needs customization based on Group IDs (which Admin would really mark guests as showing up on the Forum Team page, for example?)
(2014-05-27, 04:40 PM)laie_techie Wrote: [ -> ]-snip-
Group IDs should [strong]NOT[/strong] be hard-coded in the core (nor in plugins); permissions should be checked instead. I don't think the groups page in the ACP even needs customization based on Group IDs (which Admin would really mark guests as showing up on the Forum Team page, for example?)
That's actually a more direct point for my second suggestion, laie_techie. I actually found it quite odd that MyBB was even using GID checks in the core. I never did understand why group ID checks were used (or even necessary) to change what appears for usergroup settings in the Admin CP. I suppose you could throw out the database alternative, but they should throw out the Group ID checks in the core as well. Since permissions are already part of the core, why does it need Group ID checks at all?
This is something that could be done once work on 2.0 gets moving. These are the group ids that have been around in 1.x forever, making this change would only delay 1.8 even longer. This improvement would be nice to see in 2.0 though
.
MyBB 2.0 will be a complete rewrite so I see no reason why we shouldn't do that there - but I can't promise it. I don't think it will be "fixed" in 1.8 as I don't see a good reason for it - the id's are only used internally.
About checking for id: I think that was added before the permission system was introduced and wasn't removed then (happened on other parts too). But I don't think it's worth to fix it as it shouldn't be used that often. In addition we can't tell plugin authors how they should write their code.