cb partial config

#                     Web Application Group Configuration
# -----------------------------------------------------------------------------
#
# Some terminology:
# - Primary group: A group setting such that the setting can only be set to
#   exactly one group. Most web applications have such a feature. Very few
#   permissions systems have such a feature.
#   NOTE: If you wish to utilize the primary group synchronization feature and
#         your permissions system does not support primary groups, then you must
#         list groups you wish to be synchronized into the web applications
#         primary group field in the "groups-treated-as-primary" setting (see
#         the synchronization options below). The permissions systems that this
#         applies to are: bPerms, PermissionsBukkit, PermissionsEx, and Vault.
# - Secondary group(s): A group setting such that the setting can be set to
#   multiple groups or none.

# This section describes to Communitybridge how the web application stores
# user group/role information.
app-group-config:
  # If the web application has a primary group/role feature, configure it here.
  primary:
    enabled: true
    # The table that contains the primary group ID.
    table-name: xf_user

    # The column on the table that contains the user ID.
    user-id-column: user_id

    # If the primary group is stored in a key-value pair, set this to true.
    uses-key: false

    # The column that the primary group ID is stored in. If uses-key is true,
    # this is the column that the "value" of the key-value pair is stored in.
    group-id-column: user_group_id

    # If you set uses-key to true, then set the following three settings:
    # Key name for the key-value pair.
    key-name:
    # Column that the key name is in
    key-column:

  # If the web application has a secondary groups feature, configure it here.
  secondary:
    enabled: true
    # The table that contains the secondary groups.
    table-name: xf_user

    # The column on the table that contains the user ID.
    user-id-column: user_id

    # Storage method. Set to one of the following:
    # - single: All the group ids in a single row & column separated by the
    #           delimiter specified below.
    # - key-value: All the group ids are in a single row & column, separated
    #              by the delimiter specified below, on a table that stores
    #              its data in key-value pairs
    # - multiple-key-value: Group IDs are stored on a table of key-value pairs,
    #                    where the key name can appear in multiple rows.
    # - junction: The table can contain multiple rows for a given user_id,
    #             each with their own group_id.
    storage-method: single

    # The column that the group ID(s) are stored in:
    # (For the key-value method, this is the 'value' column)
    group-id-column: secondary_group_ids

    # For single-column or key-value storage methods, the delimiter/separator
    # that separates the group IDs:
    # (ignored for junction and multiple-key-value storage method)
    group-id-delimiter: ','

    # For the key-value storage method:
    # (ignored for the junction and single methods)
    # Key name for the key-value pair.
    key-name:
    # Column that the key name is in
    key-column:

    # This applies to the junction storage method. If there are additional columns on
    # the junction table that need to be set to a value different from the table default
    # add the column name and value to this list.
    additional-columns:
      # group_leader: 0
      # user_pending: 0

# Simple Synchronization Configuration
# NOTE: If you wish to utilize the primary group synchronization feature and
#       your permissions system does not support primary groups, then you must
#       list groups you wish to be synchronized into the web applications
#       primary group field in the "groups-treated-as-primary" setting. The
#       permissions systems that this applies to are: bPerms, PermissionsBukkit,
#       PermissionsEx, Vault, and zPermissions.
simple-synchronization:
  # Set this to true for simple synchronization
  enabled: true

  # Controls the "direction" of synchronization.
  # Options are: two-way, web-application, or minecraft.
  # - two-way: Changes on either side are synchronized to the other.
  # - web-application: Changes made in the web-application are
  #   synchronized to the Minecraft server.
  # - minecraft: Changes made in Minecraft are synchronized to the
  #   web-application.
  direction: two-way

  # If player hasn't been seen before on server, CommunityBridge will use this
  # setting to determine the direction of the synchronization. 'web-application'
  # is the only option available at this time.
  first-direction: web-application

  # Set this to true if you want the player to be notified when their primary
  # group changes.
  primary-group-change-notify: false

  # This is a safety net. Since CommunityBridge directly modifies group
  # membership information, there is a risk that a misconfiguration could
  # cause the main administrative account (e.g. super-user) of a webapp to not
  # have administrative privileges to the forum, potentially leaving the forum
  # in a state where it cannot be administered. To protect against this
  # possibility, provide the user-id of the main administrative account of the
  # web application here. Generally, this is the account created when the web
  # application was installed. For this user-id, group changes will not be
  # synchronized from Minecraft to the web application, that is, the
  # synchronization for this user will be as if direction was set to
  # 'web' (see above). Be absolutely sure this user-id is your super-user
  # all-access administrative account.
  super-user-user-id: '1'

  # If you're using primary group synchronization and a permissions system that
  # does NOT have the notion of primary groups (bPerms, PermissionsBukkit,
  # PermissionsEx, Vault) you must list permission group names that you wish to
  # be synchronized into the user's primary group field on the web application
  # here. Be sure to include these groups in the group-mapping as well.
  # Sample: groups-treated-as-primary: [guest, member, premium]
  groups-treated-as-primary: [unregistered, registered, administrative, moderating, vip, epic, hero, elite, champion, legend, ultimate, infamous, notorious, owner]

  # List groups and group IDs to be synchronized here. On the left side of
  # the colon put a web application's group ID. On the right side of the colon
  # put the corresponding permissions group name. Only list group IDs and
  # group names you wish to be synchronized.

  # NOTE: GroupManager will not create groups on the fly. So any groups you
  #       specify here must already exist. That is, you need to have used
  #       mangadd <groupname>.
  # NOTE: Regarding ladders(promotions/inherited groups): Either ALL of the
  #       groups that are part of a ladder need to have entries on this table
  #       and have corresponding group on the web application or NONE of them
  #       should be on this list. It may be that you want to use the
  #       unregistered/registered group settings instead.
  group-mapping:
    '1': 'unregistered'
    '2': 'registered'
    '3': 'administrative'
    '4': 'moderating'
    '5': 'vip'
    '6': 'epic'
    '7': 'hero'
    '8': 'elite'
    '9': 'champion'
    '10': 'legend'
    '11': 'ultimate'
    '12': 'infamous'
    '13': 'notorious'
    '14': 'owner'