Docs

docs/docs/config/adminIpList.md

@@ -4,15 +4,15 @@ permalink: /docs/config-adminIpList/
 
 # Admin IP List
 
-By [design](../overview/#architecture), _NotifyBC_ classifies incoming requests into four types. For a request to be classified as super-admin, the request's source ip must be in admin ip list. By default, the list contains _localhost_ only as defined by _adminIps_ in _/src/config.ts_
+By [design](../overview/#architecture), _NotifyBC_ classifies incoming requests into four types. For a request to be classified as super-admin, the request's source ip must be in admin ip list. By default, the list contains _localhost_ only as defined by _adminIps_ in _src/config.ts_
 
 ```ts
 module.exports = {
   adminIps: ['127.0.0.1'],
 };
 ```
 
-to modify, create config object _adminIps_ with updated list in file _/src/config.local.js_ instead. For example, to add ip range _192.168.0.0/24_ to the list
+to modify, create config object _adminIps_ with updated list in file _src/config.local.js_ instead. For example, to add ip range _192.168.0.0/24_ to the list
 
 ```js
 module.exports = {

docs/docs/config/cronJobs.md

@@ -4,15 +4,15 @@ permalink: /docs/config-cronJobs/
 
 # Cron Jobs
 
-_NotifyBC_ runs several cron jobs described below. These jobs are controlled by sub-properties defined in config object _cron_. To change config, create the object and properties in file _/src/config.local.js_.
+_NotifyBC_ runs several cron jobs described below. These jobs are controlled by sub-properties defined in config object _cron_. To change config, create the object and properties in file _src/config.local.js_.
 
 By default cron jobs are enabled. In a multi-node deployment, cron jobs should only run on the [primary node](../config-nodeRoles/) to ensure single execution.
 
 All cron jobs have a property named <a name="timeSpec"></a>_timeSpec_ with the value of a space separated fields conforming to [unix crontab format](<https://www.freebsd.org/cgi/man.cgi?crontab(5)>) with an optional left-most seconds field. See [allowed ranges](https://github.com/kelektiv/node-cron#cron-ranges) of each field.
 
 ## Purge Data
 
-This cron job purges old notifications, subscriptions and notification bounces. The default frequency of cron job and retention policy are defined by _cron.purgeData_ config object in file _/src/config.ts_
+This cron job purges old notifications, subscriptions and notification bounces. The default frequency of cron job and retention policy are defined by _cron.purgeData_ config object in file _src/config.ts_
 
 ```ts
 module.exports = {
@@ -40,7 +40,7 @@ where
 - expiredAccessTokenRetentionDays: the retention days of expired access tokens
 - _defaultRetentionDays_: if any of the above retention day config item is omitted, default retention days is used as fall back.
 
-To change a config item, set the config item in file _/src/config.local.js_. For example, to run cron jobs at 2am daily, add following object to _/src/config.local.js_
+To change a config item, set the config item in file _src/config.local.js_. For example, to run cron jobs at 2am daily, add following object to _src/config.local.js_
 
 ```js
 module.exports = {
@@ -54,7 +54,7 @@ module.exports = {
 
 ## Dispatch Live Notifications
 
-This cron job sends out future-dated notifications when the notification becomes current. The default config is defined by _cron.dispatchLiveNotifications_ config object in file _/src/config.ts_
+This cron job sends out future-dated notifications when the notification becomes current. The default config is defined by _cron.dispatchLiveNotifications_ config object in file _src/config.ts_
 
 ```ts
 module.exports = {
@@ -69,7 +69,7 @@ module.exports = {
 
 ## Check Rss Config Updates
 
-This cron job monitors RSS feed notification dynamic config items. If a config item is created, updated or deleted, the cron job starts, restarts, or stops the RSS-specific cron job. The default config is defined by _cron.checkRssConfigUpdates_ config object in file _/src/config.ts_
+This cron job monitors RSS feed notification dynamic config items. If a config item is created, updated or deleted, the cron job starts, restarts, or stops the RSS-specific cron job. The default config is defined by _cron.checkRssConfigUpdates_ config object in file _src/config.ts_
 
 ```ts
 module.exports = {
@@ -91,7 +91,7 @@ This cron job deletes notification bounces if the latest notification is deemed
 1. No bounce received since the latest notification started dispatching, and
 2. a configured time span has lapsed since the latest notification finished dispatching
 
-The default config is defined by _cron.deleteBounces_ config object in file _/src/config.ts_
+The default config is defined by _cron.deleteBounces_ config object in file _src/config.ts_
 
 ```ts
 module.exports = {
@@ -113,7 +113,7 @@ where
 
 This cron job re-dispatches a broadcast push notifications when redis cluster fails. It is part of [guaranteed broadcast push dispatch processing](../config/notification.md#guaranteed-broadcast-push-dispatch-processing)
 
-The default config is defined by _cron.reDispatchBroadcastPushNotifications_ config object in file _/src/config.ts_
+The default config is defined by _cron.reDispatchBroadcastPushNotifications_ config object in file _src/config.ts_
 
 ```ts
 module.exports = {

docs/docs/config/database.md

@@ -4,7 +4,7 @@ permalink: /docs/config-database/
 
 # Database
 
-By default _NotifyBC_ uses in-memory database backed up by folder _/server/database/_ for local and docker deployment and MongoDB for Kubernetes deployment. To use MongoDB for non-Kubernetes deployment, add file _/src/datasources/db.datasource.(local|\<env\>).(json|js|ts)_ with MongoDB connection information such as following:
+By default _NotifyBC_ uses [mongodb-memory-server](https://github.com/typegoose/mongodb-memory-server) backed up by folder _server/database/_ for local and docker deployment and a separate MongoDB for Kubernetes deployment. To use a separate MongoDB for non-Kubernetes deployment, add file _src/datasources/db.datasource.(local|\<env\>).(json|js|ts)_ with MongoDB connection information such as following:
 
 ```js
 module.exports = {

docs/docs/config/email.md

@@ -8,7 +8,7 @@ permalink: /docs/config-email/
 
 By default when no SMTP is specified, _NotifyBC_ uses fake SMTP service [Ethereal](https://ethereal.email/). Ethereal is only good for evaluation purpose as emails sent from _NotifyBC_ are delivered to Ethereal rather than actual recipients. You can access the emails from Ethereal. _NotifyBC_ automatically generates the Ethereal account first time and stores the account information in [configuration](../api/config.md) under name _etherealAccount_ accessible from _NotifyBC_ web console.
 
-For production however, setting up SMTP is **mandatory**. To do so, add following _smtp_ config to _/src/config.local.js_
+For production however, setting up SMTP is **mandatory**. To do so, add following _smtp_ config to _src/config.local.js_
 
 ```js
 module.exports = {
@@ -30,7 +30,7 @@ Check out [Nodemailer](https://nodemailer.com/smtp/) for other config options th
 
 ## Throttle
 
-_NotifyBC_ can throttle email requests if SMTP server imposes rate limit. To enable throttle and set rate limit, create following config in file _/src/config.local.js_
+_NotifyBC_ can throttle email requests if SMTP server imposes rate limit. To enable throttle and set rate limit, create following config in file _src/config.local.js_
 
 ```js
 module.exports = {
@@ -66,7 +66,7 @@ open to internet
 1. _NotifyBC_, if it can be installed on such internet-facing host directly; otherwise,
 2. a tcp proxy server, such as nginx with stream proxy module that can proxy tcp port 25 traffic to backend _NotifyBC_ instances.
 
-Regardless which above option is chosen, you need to config _NotifyBC_ inbound SMTP server by adding following static config _email.inboundSmtpServer_ to file _/src/config.local.js_
+Regardless which above option is chosen, you need to config _NotifyBC_ inbound SMTP server by adding following static config _email.inboundSmtpServer_ to file _src/config.local.js_
 
 ```js
 module.exports = {
@@ -140,9 +140,9 @@ Bounce handling involves four actions
 To setup bounce handling
 
 - set up [inbound smtp server](#inbound-smtp-server)
-- verify config _email.bounce.enabled_ is set to true or absent in _/src/config.local.js_
+- verify config _email.bounce.enabled_ is set to true or absent in _src/config.local.js_
 - verify and adjust unsubscription threshold and bounce filter criteria if needed.
-  Following is the default config in file _/src/config.ts_ compatible with [rfc 3464](https://tools.ietf.org/html/rfc3464)
+  Following is the default config in file _src/config.ts_ compatible with [rfc 3464](https://tools.ietf.org/html/rfc3464)
 
   ```ts
   module.exports = {
@@ -188,9 +188,9 @@ To support this unsubscription method, _NotifyBC_ implements a custom inbound SM
 To enable list-unsubscribe by email
 
 - set up [inbound smtp server](#inbound-smtp-server)
-- verify config _email.listUnsubscribeByEmail.enabled_ is set to true or absent in _/src/config.local.js_
+- verify config _email.listUnsubscribeByEmail.enabled_ is set to true or absent in _src/config.local.js_
 
-To disable list-unsubscribe by email, set _email.listUnsubscribeByEmail.enabled_ to _false_ in _/src/config.local.js_
+To disable list-unsubscribe by email, set _email.listUnsubscribeByEmail.enabled_ to _false_ in _src/config.local.js_
 
 ```js
 module.exports = {

docs/docs/config/httpHost.md

@@ -16,7 +16,7 @@ _httpHost_ can be overridden by other configs or data. For example
 
 There are contexts where there is no alternatives to _httpHost_. Therefore this config should be defined.
 
-Define the config, which has no default value, in _/src/config.local.js_
+Define the config, which has no default value, in _src/config.local.js_
 
 ```js
 module.exports = {

docs/docs/config/internalHttpHost.md

@@ -4,7 +4,7 @@ permalink: /docs/config-internalHttpHost/
 
 # Internal HTTP Host
 
-By default, HTTP requests submitted by _NotifyBC_ back to itself will be sent to _httpHost_ if defined or the host of the incoming HTTP request that spawns such internal requests. But if config _internalHttpHost_, which has no default value, is defined, for example in file _/src/config.local.js_
+By default, HTTP requests submitted by _NotifyBC_ back to itself will be sent to _httpHost_ if defined or the host of the incoming HTTP request that spawns such internal requests. But if config _internalHttpHost_, which has no default value, is defined, for example in file _src/config.local.js_
 
 ```js
 module.exports = {

docs/docs/config/middleware.md

@@ -4,13 +4,13 @@ permalink: /docs/config-middleware/
 
 # Middleware
 
-_NotifyBC_ pre-installed following [Express](https://expressjs.com/) middleware as defined in _/src/middleware.ts_
+_NotifyBC_ pre-installed following [Express](https://expressjs.com/) middleware as defined in _src/middleware.ts_
 
 - [compression](https://www.npmjs.com/package/compression)
 - [helmet](https://www.npmjs.com/package/helmet)
 - [morgan](https://www.npmjs.com/package/morgan) (disabled by default)
 
-_/src/middleware.ts_ contains following default middleware settings
+_src/middleware.ts_ contains following default middleware settings
 
 ```ts
 import path from 'path';
@@ -30,7 +30,7 @@ module.exports = {
 };
 ```
 
-_/src/middleware.ts_ has following structure
+_src/middleware.ts_ has following structure
 
 ```ts
 module.exports = {
@@ -45,7 +45,7 @@ module.exports = {
 
 Middleware defined under _all_ applies to both API and web console requests, as opposed to _apiOnly_, which applies to API requests only. _params_ are passed to middleware function as arguments. _enabled_ toggles the middleware on or off.
 
-To change default settings defined in _/src/middleware.ts_, create file _/src/middleware.local.ts_ or _/src/middleware.\<env\>.ts_ to override. For example, to enable access log,
+To change default settings defined in _src/middleware.ts_, create file _src/middleware.local.ts_ or _src/middleware.\<env\>.ts_ to override. For example, to enable access log,
 
 ```ts
 module.exports = {

docs/docs/config/notification.md

@@ -61,7 +61,7 @@ The config items in the _value_ field are
 
 To achieve horizontal scaling, when a broadcast push notification request is received, _NotifyBC_ divides subscribers into chunks and submits a BullMQ job for each chunk. The chunk size is defined by config _broadcastSubscriberChunkSize_. All subscribers in a chunk are processed concurrently.
 
-The default value for _broadcastSubscriberChunkSize_ is defined in _/src/config.ts_
+The default value for _broadcastSubscriberChunkSize_ is defined in _src/config.ts_
 
 ```ts
 module.exports = {
@@ -71,7 +71,7 @@ module.exports = {
 };
 ```
 
-To customize, create the config with updated value in file _/src/config.local.js_.
+To customize, create the config with updated value in file _src/config.local.js_.
 
 ::: tip When to adjust chunk size?
 
@@ -87,7 +87,7 @@ Defining custom function requires knowledge of JavaScript and understanding how
 
 :::
 
-To support rule-based notification event filtering, _NotifyBC_ uses a [modified version](https://github.com/f-w/jmespath.js) of [jmespath](http://jmespath.org/) to implement json query. The modified version allows defining custom functions that can be used in [broadcastPushNotificationFilter](../api-subscription#broadcastPushNotificationFilter) field of subscription API and [broadcastPushNotificationSubscriptionFilter](../api-notification#broadcastPushNotificationSubscriptionFilter) field of subscription API. The functions must be implemented using JavaScript in config _notification.broadcastCustomFilterFunctions_. The functions can even be _async_. For example, the case-insensitive string matching function _contains_ci_ shown in the example of that field can be created in file _/src/config.local.js_
+To support rule-based notification event filtering, _NotifyBC_ uses a [modified version](https://github.com/f-w/jmespath.js) of [jmespath](http://jmespath.org/) to implement json query. The modified version allows defining custom functions that can be used in [broadcastPushNotificationFilter](../api-subscription#broadcastPushNotificationFilter) field of subscription API and [broadcastPushNotificationSubscriptionFilter](../api-notification#broadcastPushNotificationSubscriptionFilter) field of subscription API. The functions must be implemented using JavaScript in config _notification.broadcastCustomFilterFunctions_. The functions can even be _async_. For example, the case-insensitive string matching function _contains_ci_ shown in the example of that field can be created in file _src/config.local.js_
 
 ```js
 const _ = require('lodash')
@@ -158,7 +158,7 @@ without the guarantee.
 If performance is a higher priority to you, disable both the guarantee and
 bounce handling by setting config
 _notification.guaranteedBroadcastPushDispatchProcessing_ and _email.bounce.enabled_ to
-_false_ in file _/src/config.local.js_
+_false_ in file _src/config.local.js_
 
 ```js
 module.exports = {
@@ -175,7 +175,7 @@ In such case only failed dispatches are written to _dispatch.failed_ field of th
 
 ### Also log skipped dispatches for broadcast push notifications
 
-When _guaranteedBroadcastPushDispatchProcessing_ is _true_, by default only successful and failed dispatches are logged, along with dispatch candidates. Dispatches that are skipped by filters defined at subscription (_broadcastPushNotificationFilter_) or notification (_broadcastPushNotificationSubscriptionFilter_) are not logged for performance reason. If you also want skipped dispatches to be logged to _dispatch.skipped_ field of the notification, set _logSkippedBroadcastPushDispatches_ to _true_ in file _/src/config.local.js_
+When _guaranteedBroadcastPushDispatchProcessing_ is _true_, by default only successful and failed dispatches are logged, along with dispatch candidates. Dispatches that are skipped by filters defined at subscription (_broadcastPushNotificationFilter_) or notification (_broadcastPushNotificationSubscriptionFilter_) are not logged for performance reason. If you also want skipped dispatches to be logged to _dispatch.skipped_ field of the notification, set _logSkippedBroadcastPushDispatches_ to _true_ in file _src/config.local.js_
 
 ```js
 module.exports = {

docs/docs/config/oidc.md

@@ -6,7 +6,7 @@ permalink: /docs/config-oidc/
 
 _NotifyBC_ currently can only authenticate RSA signed OIDC access token if the token is a JWT. OIDC providers such as Keycloak meet the requirement.
 
-To enable OIDC authentication strategy, add _oidc_ configuration object to _/src/config.local.js_. The object supports following properties
+To enable OIDC authentication strategy, add _oidc_ configuration object to _src/config.local.js_. The object supports following properties
 
 1. _discoveryUrl_ - [OIDC discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) url
 2. _clientId_ - OIDC client id
@@ -36,4 +36,4 @@ module.exports = {
 
 In _NotifyBC_ web console and only in the web console, OIDC authentication takes precedence over built-in admin user, meaning if OIDC is configured, the login button goes to OIDC provider rather than the login form.
 
-There is no default OIDC configuration in _/src/config.ts_.
+There is no default OIDC configuration in _src/config.ts_.

docs/docs/config/overview.md

@@ -14,14 +14,14 @@ There are two types of configurations - static and dynamic. Static configuration
 
 ## Static Configurations
 
-Most static configurations are specified in file _/src/config.ts_. If you need to change, instead of updating _/src/config.ts_ file, create local file _/src/config.local.js_ or environment specific file _/src/config.\<env\>.js_, which is only included when environment variable _NODE_ENV_ equals _\<env\>_. Besides _js_, _ts_ and _json_ file extensions are also supported. The rest of the documentation assumes the file extension is _js_. Content in these files are deeply merged in following ascending precedence
+Most static configurations are specified in file _src/config.ts_. If you need to change, instead of updating _src/config.ts_ file, create local file _src/config.local.js_ or environment specific file _src/config.\<env\>.js_, which is only included when environment variable _NODE_ENV_ equals _\<env\>_. Besides _js_, _ts_ and _json_ file extensions are also supported. The rest of the documentation assumes the file extension is _js_. Content in these files are deeply merged in following ascending precedence
 
 - default file /src/config.ts
-- environment specific file _/src/config.\<env\>.js_
-- local file _/src/config.local.js_
+- environment specific file _src/config.\<env\>.js_
+- local file _src/config.local.js_
 
 ::: warning Run build script whenever changing file in /src
-Every time a file under _/src_, including config files, is updated, run `npm run build` before restarting _NotifyBC_ to take effect.
+Every time a file under _src_, including config files, is updated, run `npm run build` before restarting _NotifyBC_ to take effect.
 :::
 
 Following configs should be customized per installation
@@ -41,7 +41,7 @@ Customizing other configs only if needed.
 
 ## Dynamic Configurations
 
-Dynamic configs are managed using REST [configuration api](../api-config/).
+Dynamic configs are managed using REST [configuration api](../api-config/). At the time of installing _NotifyBC_, no dynamic configs need to be setup.
 
 ::: tip Why Dynamic Configs?
 Dynamic configs are needed in cases such as

docs/docs/config/queue.md

@@ -34,4 +34,5 @@ module.exports = {
 };
 ```
 
-If you deployed _NotifyBC_ using Helm chart, this config is taken care of.
+If you deployed _NotifyBC_ using Helm chart, this config is taken care of. If you deployed _NotifyBC_ using docker, Redis is created inside docker using [Redis In-Memory Server
+](https://github.com/mhassan1/redis-memory-server) by default.