Supported Kazoo application documentation updates (2600hz#6216)

* Supported Kazoo application documentation updates

Provide a summary of functionality for applications that had none in
their README.md

* safely load YML and doc errors should kill the build

.aspell.en.pws

@@ -1,4 +1,4 @@
-personal_ws-1.1 en 1176 utf-8
+personal_ws-1.1 en 1177 utf-8
 ACDc
 ACDc's
 ACLs
@@ -751,6 +751,7 @@ ini
 init
 instantiation
 integrations
+integrators
 interaccount
 interdependencies
 interdigit

.circleci/config.yml

@@ -152,7 +152,7 @@ jobs:
           command: make validate-schemas
       - run:
           name: Generating docs
-          command: make docs || true
+          command: make docs
       - run:
           name: Checking doc states
           command: scripts/state-of-docs.sh || true

applications/acdc/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/ananke/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/blackhole/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/blackhole/doc/README.md

@@ -1,5 +1,7 @@
 # Blackhole - Real-time HTTP Websocket Events
 
+Blackhole creates a point of contact between KAZOO and your system, using websockets, to stream events occurring in KAZOO to your connected session(s). Blackhole is effectively an AMQP->Websocket bridge, providing you with real-time event streams about calls, API changes, and more.
+
 ## Setting up
 
 1. Start the Blackhole Crossbar module

applications/braintree/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/call_inspector/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/callflow/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/camper/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/cccp/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/cdr/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/cdr/doc/README.md

@@ -1,3 +1,3 @@
+# CDR - *Call Detail Records*
 
-# CDR *Call Detail Records*
-For all your call detailing needs
+When calls finish, the CDR app receives the `CHANNEL_DESTROY` event, massages some of the values, then stores the CDR to the account's MODB.

applications/conference/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/conference/doc/README.md

@@ -1,4 +1,3 @@
+# Conference App
 
-# Conference
-This app should have been called "party line"...
-
+The conference app manages the discovery of where a conference has/will be started as well managing the participants in the conference. Additionally, the app manages the configurations for the conference rooms supplied to FreeSWITCH/mod_conference.

applications/crossbar/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/doodle/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/doodle/doc/README.md

@@ -1,4 +1,3 @@
-
 # Doodle *Store and Forward SMS*
 
-"Stop that pigeon!"
+IM services, like SMS and MMS routing.

applications/ecallmgr/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/ecallmgr/doc/README.md

@@ -1,3 +1,7 @@
-
 # ecallmgr *Erlang Call Manager*
-Managing your calls from Erlang
+
+Ecallmgr connects to and manages the FreeSWITCH servers and the interactions between higher-level applications and the FreeSWITCH layer.
+
+## Overview
+
+Higher-level applications don't need to know which FreeSWITCH server the call they're processing is located on. Ecallmgr manages the bookkeeping of where calls and conferences are, as well as providing an abstraction layer over the particulars of the FreeSWITCH commands.

applications/edr/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/fax/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/fax/doc/README.md

@@ -1,4 +1,3 @@
-
 # Fax
 
 Faxing is still a critical business requirement for many industries. The faxes app provides a set of faxing related features to kazoo accounts and supports sending and receiving faxes directly from email or the API. The fax entities can be tied to a callflow to terminate incoming faxes without having to use a fax machine.

applications/frontier/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/hangups/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/hotornot/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/jonny5/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true

applications/jonny5/doc/README.md

@@ -1,143 +1,11 @@
+# Jonny5
 
-# Overview
+Jonny5 maintains the current state of call limits as applied to accounts and their resellers.
 
-The Skel application serves as the barest of examples of creating a listener on
-the AMQP message bus, handling the JSON requests that come in, and responding
-with JSON as appropriate.
+Accounts can have a number of limits applied to them when placing calls:
 
-The example listener is for route requests, but the reader should know that
-several other requests exist, not limited to authentication, authorization, and
-other whapp-specific requests.
+- Trunk-based: Inbound, outbound, two-way, burst, bundled
+- Credit-based: Prepay, postpay
+- Allotments: Minutes in monthly, weekly, daily, hourly, or minutely buckets
 
-## The Listener
-
-Generally speaking, most action starts at the listener. The listener typically
-builds on top of the gen_listener pattern (found in lib/kazoo-1.0.0/src) to
-abstract the AMQP connection and reception of payloads off the message bus.
-Instead, the gen_listener behaviour allows the implementing module to specify
-the types of events to pull off the AMQP bus, and the handler modules/functions
-for each type of JSON payload received. The handlers run as processes separate
-from the listener process, allowing it to consuming AMQP payloads as quickly as
-possible.
-
-The main areas of the listener that need editing are the bindings, responders,
-optional queue name, queue options, consume options, and QoS for initialization,
-and the handle_event/2 callback.
-
-### Initialization
-
-The full example first:
-
-~~~
-  gen_listener:start_link(?MODULE
-                          ,[{bindings, [{api_module, [options]}
-                                        ,{other_api_module, [options]}
-                                       ]}
-                           ,{responders, [{ {callback_module, callback_function}
-                                            ,[{<<"category">>, <<"name">>}]
-                                          }
-                                         ]}
-                           ,{queue_name, <<>>}
-                           ,{queue_options, []}
-                           ,{consume_options, []}
-                           ,{basic_qos, 1}
-                          ], []).
-~~~
-
-#### Bindings
-
-The AMQP APIs available can be found in the modules in lib/kazoo-1.0.0/api/
-(prefixed with kapi_) and define the bindings needed to receive AMQP payloads of
-a certain type.
-
-For instance, to receive route requests, one would add the 'route' binding and
-payloads sent directly to our queue, one would configure the bindings list like:
-
-~~~
-  {bindings, [{route, []}
-              ,{self, []}
-             ]
-  }
-~~~
-
-These two 2-tuples will cause the gen_listener to call kapi_route:bind_q/2 and
-kapi_self:bind_q/2 with the listener's queue. When shutting down the listener,
-the unbind_q/2 variants will be called to cleanup the AMQP bindings.
-
-Some of the kapi modules allow parameters to be passed in the second element of
-the tuple, changing either what bindings are added, or the binding key used. For
-instance, in lib/kazoo-1.0.0/src/api/kapi_route.erl, one can see in the
-bind_q/2 function that one could specify a realm, which would restrict the route
-requests received by this listener to just the realm.
-
-#### Responders
-
-Now that we've bound to all appropriate AMQP messages we want to consume, we
-need to tell the gen_listener behaviour what to do with them when received. To
-do this, we pass in a list of responder module/function pairs and a list of
-event category and name pairs.
-
-In the case of binding to route requests, we know to expect to receive events
-with ("dialplan", "route_req") as the category/name. So we create a responder
-module skel_route_req.erl and define a handle_req/2 function. In the start_link
-parameters, we would inform gen_listener of this like so:
-
-~~~
-  {responders, [{{skel_route_req, handle_req}, [{<<"dialplan">>, <<"route_req">>}]}]}.
-~~~
-
-As you can see, the same callback can take more than one category/name pair. One
-could also create one callback module (skel_handlers, for instance) with a
-handle_* function specific to each type of category/name pair.
-
-If you want to handle more than one type of name for a given category, you can
-use the <<"*">> to match any category or name. So, if we expect multiple event
-names for the dialplan category, and we want to use the same handler for each,
-we could denote that like:
-
-~~~
-  {responders, [{{skel_handlers, handle_dialplan_req}, [{<<"dialplan">>, <<"*">>}]}]}
-~~~
-
-#### The rest
-
-queue_name: If you want an auto-generated, anonymous queue, you can omit the
-queue_name tuple, or set it to {queue_name, <<>>} (this is the default). If you
-want to use a named queue, include the name as the second element:
-{queue_name, <<"named_queue">>}.
-
-queue_options: Another parameter that can be omitted from the list of configs
-sent to gen_listener, use this if you need different values than in
-lib/kazoo_amqp-1.0.0/src/amqp_util.erl, the new_queue/2 function. This list
-controls how the broker creates the queue.
-
-consume_options: Omittable as well, these options control how consumption from
-the queue will be managed (see basic_consume/2 in amqp_util.erl).
-
-basic_qos: Only needed if you need to control prefetch count from the queue to
-multiple consumers; otherwise omit from the list.
-
-#### handle_event/2
-
-The one interaction with the AMQP payload the listener module has is with the
-handle_event/2 callback. Before calling into the handler module(s)' functions,
-the gen_listener will pass the payload and the listener's state, allowing the
-listener to pass back a proplist of values the callbacks may need/want. The
-response from handle_event/2 should be {reply, ConfigList}, where ConfigList is
-an empty list or a list of key/value tuples.
-
-This ConfigList is prepended with the following default config pairs:
-{queue_name, Name} and {server, pid()}. Name is the name of the AMQP queue
-(needed when the callbacks might need responses to their own AMQP requests (and
-why you typically bind with {self, []}). The pid() is the PID of the listener
-process, in case you need to make queries from the process's state.
-
-The ConfigList ++ [{queue_name, Name}, {server, pid()}] is passed as the second
-argument to the handler module(s)' functions (the first being the AMQP payload.
-
-
-## Other setup
-
-Add the whapp directory name to kazoo_apps/rebar.config to make sure it gets
-compiled by default when running 'rebar compile' from either the root or
-kazoo_apps directory.
+Each leg of a call is then evaluated and tracked by jonny5 to ensure an account (and their reseller) stay within their configured limits.

applications/konami/.circleci/config.yml

@@ -299,7 +299,7 @@ jobs:
           command: make -C ${KAZOO_ROOT} validate-schemas
       - run:
           name: Generating docs
-          command: make -C ${KAZOO_ROOT} docs || true
+          command: make -C ${KAZOO_ROOT} docs
       - run:
           name: Checking doc states
           command: ${KAZOO_ROOT}/scripts/state-of-docs.sh || true