No announcement yet.

Explanation - Using Secondary Groups

  • Filter
  • Time
  • Show
Clear All
new posts

  • Explanation - Using Secondary Groups

    Secondary groups are extremely powerful, but their concept can be confusing. This post will attempt to clarify what they do and how they can be used.

    With the introduction of secondary groups in vB3, users are now able to belong to multiple usergroups at once. A user will always have one primary group, but they can belong to any number of secondary groups. The permissions from a user's secondary groups merge together in determining their final permissions, such that one Yes permission overrides all other No permissions. For example, if a user is a member of one primary group (pgroup) and two secondary groups (sgroup1, sgroup2), and the Can Post Threads permission looks like this among all of the groups:

    pgroup - No
    sgroup1 - No
    sgroup2 - Yes

    ...then the overall Can Post Threads permission for that user will be Yes, because one Yes overrides any number of No's.

    As for how this can be used to an advantage... consider the scenario where you have 3 main types of members on your forum (type1, type2, type3). Each of these three types have access to different forums as set in the:

    Admin CP -> Forums & Moderators -> Forum Permissions

    Let's say each type of member has their own private forum which the other types cannot access.

    Now you want to add a fourth private forum to which some users of each type will have access, but not all users. This means you will have 6 types of members instead of 3, because each of the original types needs to be split so some of each type can have access to the fourth private forum. This is where you can use secondary groups to your advantage.

    Instead of creating 3 new groups to accomodate the 3 new combinations of permissions, you can create just one new group that has access to the fourth private forum. Then you can add users from any of the original 3 groups to the new group using a secondary group membership. The primary group memberships will not change, but some users will now belong to a secondary group in addition to their primary group. This secondary group membership will grant access to the fourth private forum, completely independent of your primary groups. This solution is much more elegant than creating 3 new primary groups to account for the 3 new possible combinations.

    So Why Have Multiple Primary Groups?
    Why not just put everyone in the same primary group and grant all permissions using secondary groups? Wouldn't this maximize the ease of assigning permissions.

    For one thing, under the current system (3.0.3), new registrations are always put into 1 of 3 primary groups:

    - Registered Users
    - Unregistered / Not Logged In
    - Users Awaiting Email Confirmation

    There is no option to specify secondary group memberships for new registrations, and so primary groups are necessary.

    Also, primary groups are convenient for assigning a base set of permissions to your users. You can use secondary groups to add on bits and pieces, but the base permissions are more easily defined in a primary group.

    But more importantly, primary groups are used to qualify users for ranks and promotions. Building on the previous example with the fourth private forum... we might not want a type1 member to have the same ranks as a type2 member, even though they can both have access to the fourth private forum. Similarly, we might have a promotion path setup for type1 members that we don't want type2 members to have. This separation of ranks and promotions is yet another layer of independence that gives you greater power to manage your members.

    To summarize, primary groups are used to qualify members as a certain type, and secondary groups are used to grant permissions that are available to multiple types of members.

    Example Of A Forum Setup:
    You might use primary groups to represent these types of members:

    - random registration
    - long time member
    - personal friend
    - moderator might want both your moderators and personal friends to have access to your moderator forum, and so you could use a secondary group to grant access to that forum:

    - mod forum access

    ...then you might want to setup a promotion from random registration to long time member after they have been registered for... say 6 months. You can create this promotion so that only random registrations can qualify. You probably wouldn't want your moderators getting demoted to long time members.
    Last edited by Jake Bunce; Sun 5 Dec '04, 1:24pm.

  • #2
    Small correction...

    After doing some testing, it appears secondary groups can indeed qualify users for ranks, but a user needs to choose to identify with that group in their:

    User CP -> Group Memberships

    So ranks go by the user's Display Usergroup, which can be either a primary or secondary group.

    Promotions still use only the Primary Usergroup.
    Last edited by Jake Bunce; Tue 21 Dec '04, 4:19pm.


    • #3
      Another small detail...

      In order for secondary group memberships to have any effect on permissions, the primary group(s) in question must have this option enabled:

      Admin CP -> Usergroups -> Usergroup Manager -> Edit Usergroup -> Allow Users to have Member Groups

      If this option is not enabled for the primary group(s) in question, then secondary groups will have no effect on permissions.

      Secondary groups still have uses even with this option disabled. For example, you might use secondary groups as flags for template conditionals. One common thing that forum admins will do is to disable banner ads for contributing members. You can create a secondary group to represent contributors, and then use code like this in your templates:

      <if condition="!is_member_of($bbuserinfo, [color=red]X[/color])">
      Where X is the usergroupid of your contributor group. This code basically says, if the logged in user is not a member of group X (is not a contributor) then show the banner ad.


      widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.