configuration.sample.jsonc

{
    "$schema": "https://raw.githubusercontent.com/linaro-its/sd-webhook-framework/master/schema.json",
    // HANDLER MAPPINGS
    //
    // Declare which request types map onto which handler. In the (very)
    // unlikely situation that there is a handler that supports all non-specified
    // request types, the wildcard ("*") entry can be used.
    //
    // Normally, each line would look something like this:
    // "265": "rt265_handler"
    // where "265" is the request type number and the right-hand side is the
    // filename for the associated handler. NOTE: the filename does NOT end
    // with ".py". That is handled automatically by the framework.
    //
    // These mappings can be ignored if the handler filename matches the
    // format "rt<request type number>.py", e.g. "rt265.py". However, since
    // request type numbers are not particularly intuitive, using mappings and
    // sensible filenames for the handlers is better in the long run.
    "handlers": {
        // Not necessarily a good idea to leave this in on a production system!
        "*": "rt_example_handler"
    },

    // CUSTOM FIELDS
    //
    // Specify a JSON file to be used as the cache of IDs for custom fields. Note that
    // if this is left commented out, the code will default to using the cf_cachefile
    // that is included in the repo.
    // "cf_cachefile": "~/cf_cachefile.json",
    //
    // Use the Server REST API to retrieve custom fields?
    "cf_use_server_api": false,
    //
    // Use the Cloud REST API to retrieve custom fields?
    "cf_use_cloud_api": false,

    // VAULT AUTHENTICATION
    //
    // Common Vault configuration items if Hashicorp Vault is being used to store
    // secrets.
    // "vault_iam_role": "aws-iam-role",
    // "vault_server_url": "https://vault.example.com",

    // SERVICE DESK
    //
    // The account to be used for *all* Service Desk operations.
    "bot_name": "valid-account-name",
    //
    // Either specify a password for the "bot" ...
    // "bot_password": "valid-account-password",
    //
    // or specify the following Vault parameter:
    // "vault_bot_name": "secret/blob/bot_name",
    //
    // There seems to be a race condition in Jira Service Management Cloud when
    // using the APIs to set the approver list. Atlassian's suggested workaround
    // is to have an automation rule that is a webhook to set the Approvers.
    //
    // If the following value is defined, the framework will trigger the webhook
    // rather than try to use the API for any attempts to set the specified
    // custom field.
    // "jsm_customfield_webhook": {
    //     "cf_xxxx": "URL-to-xxxx-webhook",
    //     "cf_yyyy": "URL-to-yyyy-webhook"
    // },

    // GOOGLE
    //
    // Set to "false" if you don't use or need Google integration
    "google_enabled": false,
    //
    // Admin account (used for some delegated authentication)
    // "google_admin": "wibble@wibble.com",
    //
    // Either specify a path to the service account JSON file ...
    // "google_json_file": "",
    //
    // or specify the following Vault parameter:
    // "vault_google_name": "secret/blob/google_name",

    // LDAP
    //
    // Set to "false" if you don't use or need LDAP integration
    "ldap_enabled": false,
    //
    // Set this to be the name of your LDAP server.
    // "ldap_server": "ldaps://ldap-server",
    //
    // Set this to be the base DN that you want to use. Leave blank
    // if you want the code to automatically determine the base DN.
    // "ldap_base_dn": "",
    //
    // Set this to be the default OU in which to place new accounts.
    // The base DN will be appended.
    // "ldap_default_account_ou": "ou=accounts",
    //
    // Set this to be the OU for security groups. The base DN will
    // be appended.
    // "ldap_security_groups": "ou=security",
    //
    // Set this to be the OU for mailing groups. The base DN will be
    // appended.
    // "ldap_mailing_groups": "ou=mailing",
    //
    // Set this to be a user on LDAP with sufficient privileges.
    // "ldap_user": "valid-ldap-DN",
    //
    // Either specify a password for the ldap-user ...
    // "ldap_password": "valid-ldap-password",
    //
    // or specify the following Vault parameter:
    // "vault_ldap_name": "secret/blob/ldap_name",

    // EMAIL
    //
    // Two mechanisms are supported in the framework for sending email:
    //
    // 1. SMTP via a relay host
    // 2. AWS SES
    //
    // Uncomment one of the following lines as appropriate. If both are left
    // commented out, attempts to send email will raise an error.
    // "mail_mechanism": "smtp",
    // "mail_mechanism": "ses",
    //
    // SMTP CONFIGURATION
    // Note that if you are using the Docker container, you either need to
    // configure the host's MTA to listen to the Docker IP address or you
    // need to run a separate container and network it to the framework
    // container. Either way, you need to specify an IP address here.
    //
    // If it is commented out and "mail_mechanism" is set to "smtp", attempts
    // to send email will raise an error.
    // "mail_host": "172.17.0.1",
    //
    // Uncomment if a port other than 25 is needed.
    // "mail_port": 587,
    //
    // Uncomment if SSL is required for the email connection. If using the MTA
    // on the host, this would be an unnecessary overhead since all network
    // traffic is internal.
    // "mail_ssl": true,
    //
    // Sending username. Leave commented out if no authentication is required.
    // "mail_user": "",
    //
    // If authentication is required, either specify a password ...
    // "mail_password": "",
    //
    // or specify the Vault path to the account's password:
    // "vault_mail_name": "",
    //
    // SES CONFIGURATION
    //
    // The following setting is required and must be correct for your SES
    // settings.
    // "ses_region": "us-east-1",
    // The following setting is optional and can be left commented out.
    // "ses_config_set": "ConfigSet",

    // Don't touch ...
    // Leave this entry here so that higher entries can be commented in or
    // out without worrying about trailing commas.
    "final_entry": "Finished"
}