This is the default config.yml file generated by CommunityBridge when the CommunityBridge plugin directory does not have a config.yml.

CB-Default-Config.yml

#                  Community Bridge Configuration File
# -----------------------------------------------------------------------------

#                             General Settings
# -----------------------------------------------------------------------------
general:
  # Log level controls the degree of detail that is sent to the console/log
  # The possible settings are (in order of quietest to noisiest:
  #   info, config, fine, finer, finest, all
  # - During configuration, I recommend using 'config'.
  # - During normal operation, I recommend using 'info'.
  # - If you want to see the notifications that the synchronize and reminder
  #   notices have been sent, use 'fine'
  # - During troubleshooting of problems, set this to either finest or all.
  log-level: config

  # Allow plugin metrics to start up for this plugin. Please turn on
  # metrics! It helps plugin authors determine what features to include!
  # For more details see:
  # http://dev.bukkit.org/bukkit-plugins/communitybridge-fm/pages/why-plugin-metrics/
  # Enable/Disable for all plugins by editing plugins/PluginMetrics/config.yml
  # and setting 'opt-out' to false.
  plugin-metrics: true

  # Turns on the achievements (rewards) system. See achievements.yml for more
  # information.
  use-achievements: false

  # Set the unit of measurement for sync and reminder scheduling. Options are:
  # ticks, seconds, minutes, hours, or days. Note that this applies to both
  # auto-sync-every and auto-remind-every.
  auto-every-unit: minutes

  # This is a timer that will check and sync all data with your database at a
  # set interval. Otherwise group and player statistics will only be
  # synchronized when the player joins and leaves the Minecraft server.
  auto-sync: true

  # The interval for the auto-sync timer, this should not be set any lower than
  # 20 minutes.
  auto-sync-every: 20

  # Enables/disables synchronization during join and quit events. Recommend both
  # being set to true.
  sync-during-join: true
  sync-during-quit: true

  # NOTE: GroupManager will not create groups on the fly. So any groups you
  #       specify in the linking or synchronization sections must already
  #       exist. That is, you need to have used mangadd <groupname>)
  #       Also, GroupManager announces primary group changes with no option
  #       to override this behavior.
  # NOTE: PermissionsBukkit will not create groups on the fly. So any groups you
  #       specify in the linking or synchronization sections must already
  #       exist.
  # NOTE: zPermissions will not create groups on the fly. So any groups you
  #       specify in the linking or synchronization sections must already
  #       exist. That is, you need to have used: permissions group <group>
  #       create. Further, zPermissions lacks a real API. A player's group
  #       assignment can fail without CommunityBridge being aware of the
  #       failure.

  # The permissions system you're using. A permissions system is required for
  # the following features:
  # * Group Synchronization (both primary and secondary)
  # * Unregistered/Registered group assignment (sub-features of 'linking')
  # Current Options are: bPerms, GroupManager, PermsBukkit, PEX, Vault,
  #                      zPermissions.
  permissions-system:

  # If ~APPURL~ appears in a message in messages.yml, it will be replaced with
  # this:
  application-url:

  # Set the date format for any of the dates used by CommunityBridge.
  date-format: "yyyy-MM-dd hh:mm:ss a"

#                             Database Settings
# -----------------------------------------------------------------------------
# Please ensure if you run your Minecraft server on a remote host
# that your MySQL server allows REMOTE connections. This WILL NOT WORK unless
# your MySQL server is configured to allow connections from the machine that
# your Minecraft server is running on. If you don't know what that means,
# consult your hosting provider on how to configure your MySQL server correctly.
# All of this information should be the same server and database used by your
# web-application...
database:
  # Hostname for your MySQL Server
  hostname: localhost

  # MySQL Port
  port: 3306

  # Database Name
  name: databasename

  # Database Username
  username: username

  # Database Password
  password: password

  # SQL binding address
  # Normally you won't need to set anything here.
  # Recommended setting is blank.
  # If needed the local binding address for the SQL client can be set here.
  # Use 'minecraft' to use the address set in the server.properties.
  binding-address:

#                             Player Linking Settings
# -----------------------------------------------------------------------------
# Settings associated with linking a Minecraft player with a web application's
# user. As this feature is a prerequisite for all other features, it cannot
# be disabled.
player-user-linking:
  # Use this to specify which method you are using: uuid, name, or both.
  # uuid - Players are identified by uuid in your web application's database.
  # name - Players are identified by player name in your web application's database.
  # both - Communitybridge will try both ways before giving up.
  linking-method: both

  # If you want the player disconnected from the game if they haven't
  # registered, then set this to true. They will be shown the
  # link-unregistered-player message (in message.yml) on the disconnected
  # screen.
  kick-unregistered: false

  # This is a timer that will notify unregistered users to register every few
  # minutes.
  auto-remind: true

  # The interval for the auto-remind timer, this should be no less than
  # 5-10 minutes. Note that this uses the units specified above in
  # auto-every-unit.
  auto-remind-every: 10

  # Set these to true to inform players when they log in if they're linked to
  # the web application. These correspond to the link-unregistered-player and
  # link-registered-player messages in messages.yml.
  notify-registered-player: true
  notify-unregistered-player: true

  # If you have a permissions system and you want the player to be placed
  # in a group based on (un)registered status, set the following.
  # If left blank the setting won't be used. If a group-synchronization
  # feature is turned on, the 'registered-player-group' won't be used.
  # NOTE: GroupManager will not create groups on the fly. So the groups you
  #       specify here must already exist. That is, you need to have used
  #       mangadd <groupname>)
  unregistered-player-group:
  registered-player-group:
  notify-player-of-group: true

  # If you want a player to be added to the 'registered-player-group' ONLY if:
  # * they are a member of the unregistered-player-group OR
  # * they have no assigned groups
  # then set this to true.
  registered-former-unregistered-only: true

  # If you want a player to be added to the 'unregistered-player-group' if they
  # are no longer registered, set this to true.
  unregister-former-registered: false

  # This is where we specify how to associate a Minecraft player with a web
  # application user. We do this by matching up the player name with a name
  # stored in the web application's database.
  #
  # If you want your players to use the same name on both the server and the
  # web application, then you will need to provide the table and column
  # information where the web application relates its user IDs with the user's
  # name/login ID/login/username.
  #
  # If you want to allow them to use a different name on the web application,
  # you need to add a custom field or column to your web application's database
  # for their minecraft name and specify below where the minecraft name is stored
  # in the web application's database.

  # The name of the table which contains the columns:
  table-name:

  # Column on the table that contains the user ID. Typically, the column will be
  # named something like user_id or member_id and contains a unique number for each
  # user.
  user-id-column:

  # If the player name is stored in a key-value pair of columns instead of
  # its own column, set this to true:
  uses-key: false

  # If you set 'linking-uses-key' to false, then set this to the column that
  # the minecraft uuid or playername is stored in. Otherwise, leave it empty.
  identifier-column:

  # If you set 'linking-uses-key' to true, then set the key column, value
  # column, and the key-name here. Otherwise, leave these fields empty.
  key-name:
  key-column:
  value-column:

# Used either for requiring and avatar or rewarding the existence of an avatar.
app-avatar-config:
  enabled: false
  # Table that contains the avatar column
  table-name:
  # Column on the avatar table that contains the user ID.
  user-id-column:
  # Column on the avatar table that contains the avatar information. If this
  # column contains data, the user is assumed by CommunityBridge to have an
  # avatar.
  avatar-column:

# Used for post count awards or for requiring a post count.
app-post-count-config:
  enabled: false
  # Table that contains the post count column
  table-name:
  # Column on the avatar table that contains the user ID.
  user-id-column:
  # Column containing the user's post count.
  post-count-column:

#                             Requirements
# -----------------------------------------------------------------------------
requirement:
  # Set this to true to require an avatar to be set to access the game.
  # Requires app-avatar-config settings to be enabled and configured correctly.
  avatar: false
  # Require the player to have at least this many posts before being able to
  # play. Requires app-post-count-config settings to be enabled and configured
  # correctly.
  post-count:
    enabled: false
    minimum: 0

#                             Statistics Tracking
# -----------------------------------------------------------------------------
# In general, to make this work, your web application will need to support
# custom profile fields or a similar feature. CommunityBridge will put the
# information in the database. It is up to you to configure your web application
# so that it displays the information.
statistics:
  # Enables statistics tracking. Nothing will be tracked unless you also enable
  # at least one of the trackers below.
  enabled: false
  # Name of the table to insert the tracking information on to.
  table-name:
  # Name of the column that contains the player's User ID on the table.
  user-id-column:
  # Set this to true if data on the table is stored in key-value pairs.
  uses-key: false

  # If uses-key is true, set these as well. These settings are not used if
  # uses-key is false.
  key-column:
  value-column:

  # Some web applications require an insert the first time a custom profile
  # field is filled with data (SMF, for example). If that's the case, enable
  # this and provide the required information.
  insert:
    enabled: false
    # Options are: generic and smf.
    method: generic

    # Required for the 'smf' method, ignored for other methods. Most likely id_theme.
    theme-id-column: id_theme

    # Required for the 'smf' method, ignored for other methods. Most likely value is 1.
    theme-id: 1

  # Individual trackers
  # -------------------
  trackers:
    # Below each tracker can be enabled and configured. For each tracker:
    # * If uses key is true, set column-or-key-name to the key name OR
    #   If uses key is false, set column-or-key-name to the column name
    # For some trackers, there is a formatted version as well. For those
    # trackers, the formatted version is optional. If you wish to use the
    # formatted version, set the formatted-column-or-key-name appropriately.
    # If set, the formatted column will be filled in with a human readable
    # string.

    # Online Status: Show a player is playing on the server in the forums.
    online-status:
      enabled: false
      column-or-key-name:
      # Set this to what should be stored in the field when the user is online.
      online-value:
      # Set this to what should be stored in the field when the user is offline.
      offline-value:

    # Last Online: Record the time that player was last online
    last-online:
      enabled: false
      # Numeric column, should be able to store a 32 bit integer. Will be seconds since epoch.
      column-or-key-name:
      # String (varchar, etc.) column at least 60 characters in length.
      formatted-column-or-key-name:

    # Game Time: Record how much time the player has played.
    # Requires the last-online tracker to be turned on as well.
    game-time:
      enabled: false
      # Numeric column, should be able to store a 32 bit integer. Time played in seconds.
      column-or-key-name:
      formatted-column-or-key-name:

    # Player's current level
    level:
      enabled: false
      # Numeric column, a single byte will be sufficient in most cases.
      column-or-key-name:

    # Player's current progress toward next level
    current-xp:
      enabled: false
      # Numeric floating point column.
      column-or-key-name:
      # String column with at least 4 characters capacity.
      formatted-column-or-key-name:

    # Player's XP total
    total-xp:
      enabled: false
      # Numeric column, capable of storing a 32 bit integer.
      column-or-key-name:

    # Player's current health
    health:
      enabled: false
      # Numeric column, a single byte should be sufficient.
      column-or-key-name:

    # Lifeticks; the amount of time the player has been alive.
    lifeticks:
      enabled: false
      # Numeric column, capable of storing a 32 bit integer.
      column-or-key-name:
      # String field with at least 100 characters of storage.
      formatted-column-or-key-name:

    # Wallet. The amount of money the player currently has. REQUIRES VAULT.
    wallet:
      enabled: false
      # Numeric column capable of storing a "double" floating point number.
      column-or-key-name:

#                     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. A given player/user can be a member
#   of only one primary group at a time.
#   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. A given player/user can be a member multiple
#   secondary groups at a time in addition to being member of a single
#   primary group.

# 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: false
    # The table that contains the primary group ID.
    table-name:

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

    # 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:

    # 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: false
    # The table that contains the secondary groups.
    table-name:

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

    # 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:

    # 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: false

  # 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: ''

  # 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]
  #         note that the brackets are required.
  groups-treated-as-primary: []

  # If you have groups that are secondary groups on the web application that
  # you wish to be treated as if they are primary on your permissions system
  # (that is, these groups will be mutually exclusive), List them here.
  # Sample: groups-treated-as-primary: [guest, member, premium]
  #         note that the brackets are required.
  webapp-secondary-groups-treated-as-primary: []

  # 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' : 'guest'
    '2' : 'member'
    '3' : 'premium'

ban-synchronization:
  enabled: false

  # 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

  # Method options:
  # - table: Banned users will be inserted and deleted from a table that is a list of bans
  # - user: A column on the users/members table designates whether a user is banned.
  # - group: Specify a web-application group whose members are banned. Specify whether
  #          the group is a primary or secondary group and configure app-group-config
  #          above as appropiate.
  method: table

  # Group method settings
  # Group type is either primary or secondary
  group-type:
  banned-group:

  # Name of the table that holds ban information for your web application. Only needed for
  # user and table methods.
  table-name:

  # Column that contains the user ID of the banee. Only needed for the user and table methods.
  banned-user-id-column:

  # Settings for the user method. Only needed if method above is set to user
  # The value parameters can be strings, numbers, whatever your web application
  # uses to indicate the user is banned or not.
  ban-column:
  value-banned:
  value-notbanned:

  # Settings for table method. Only needed if method above is 'table'. Set
  # options that seem relevant to your web application.
  # The column containing the reason for the ban. Leave blank if your web
  # application does not support this.
  ban-reason-column:
  # The column containing the ban start time (systime expected). Leave blank
  # if your application does not support this.
  ban-start-column:
  # The column containing the ban end time (systime expected). Leave blank
  # if your application does not support this.
  ban-end-column:
  # The column containing ban-group-id. Leave blank if your web application
  # does not support this.
  ban-group-id-column:
  # The ban-group-id. Leave blank if your web application does not support this.
  ban-group-id: