@planningcenter/add-ons-cli

Planning Center Add-ons CLI

This little app build and updates Planning Center Add-ons from the command line.

To install:

• Install the package: npm install @planningcenter/add-ons-cli
• Run the binary planningcenter-add-ons -h

The main commands are:

• create : creates a new skeleton add-on with sample code
• update : bundles and uploads add-on code to Planning Center
• watch : watch the files in the add-on directory and run update when they change
• promote : copies bundled JS code from testing to beta, or from beta to production environment

Request Flow for update / promote

ensure the add-on's oauth app has the right scopes

PATCH /api/v2/oauth_applications/:id
{ "data": { "attributes": { "add_on_scopes": "people" } }

get details about the oauth app's integrator add-on

there's an integrator_add_on record per add-on environment: testing, beta, and production.

GET /api/v2/oauth_applications/:id/integrator_add_ons

for each environment

up to 3 (testing, beta, production)

if there isn't an integrator add-on for the environment

POST /api/v2/oauth_applications/:id/integrator_add_ons
{ "data": { "attributes": {
  "environment": "",
  "oauth_authorize_url": "",
  "oauth_token_url": "",
  "oauth_identifier": "",
  "oauth_secret": "",
  "oauth_scopes": "",
  "oauth_redirect_uri": "",

  "target_organization_ids?": ""
} } }

if there is an integrator add-on for the environment

same as the post, but a patch to ensure it still matches the user's config this happens up to 3x (per environment)

PATCH /api/v2/oauth_applications/:id/integrator_add_ons/:id
{ "data": { "attributes": {
  "environment": "",
  "oauth_authorize_url": "",
  "oauth_token_url": "",
  "oauth_identifier": "",
  "oauth_secret": "",
  "oauth_scopes": "",
  "oauth_redirect_uri": "",

  "target_organization_ids?": ""
} } }

get details about the integrator add-ons's ui_extensions

GET /api/v2/oauth_applications/:id/integrator_add_ons/:id/ui_extensions

for each insertion point the user's creating a ui_extension for

up to 3 currently, but could be more: people.list.send_message, people.dashboards.background_checks.new, people./profile.background_checks.new

in test, we're uploading data.attribute.bundle that is the add-on's javascript code. in non-test, we're expecting to use a bundle_url that was set when the test ui extension was created or updated

if there isn't a ui extension already

POST /api/v2/oauth_applications/:id/integrator_add_ons/:id/ui_extensions
{ "data": { "attributes": {
  "component_version": "",
  "icon_url": "",
  "insertion_point": "",
  "title": "",

  "bundle_url?": ""        if !env.test?
  "bundle?": "<js string>" if env.test?
} } }

if there is an existing ui extension

PATCH /api/v2/oauth_applications/:id/integrator_add_ons/:id/ui_extensions/:id
{ "data": { "attributes": {
  "component_version": "",
  "icon_url": "",
  "insertion_point": "",
  "title": "",

  "bundle_url?": ""        if !env.test?
  "bundle?": "<js string>" if env.test?
} } }