Angular 18 upgrade rebase

PAYMENTS.md

@@ -5,34 +5,35 @@ The "**Web Money block**" can be used in a flow to stream ILP payments in real t
 We enable Coil users to stream XRP using Web Monetization's Interledger Protocol. The block works with, or without the Coil browser extension, and the account balances can be seen by recipients using the Wallet block to see (currently integrated using Uphold OAuth).
 
 Check out the screencast videos:
--   [Kendraio Player with Coil login, Web Monetization without a browser extension](https://www.youtube.com/watch?v=T2yXWJKIgOQ)
 
--   [Uphold API integrated with Kendraio App Wallet Block](https://www.youtube.com/watch?v=QoZA2F-ddd8)
+- [Kendraio Player with Coil login, Web Monetization without a browser extension](https://www.youtube.com/watch?v=T2yXWJKIgOQ)
+
+- [Uphold API integrated with Kendraio App Wallet Block](https://www.youtube.com/watch?v=QoZA2F-ddd8)
 
 **Block documentation**
 
--   [Web Money Block](https://github.com/kendraio/kendraio-app/blob/main/docs/workflow/blocks/web_money.rst)
+- [Web Money Block](https://github.com/kendraio/kendraio-app/blob/main/docs/workflow/blocks/web_money.rst)
 
--   [Wallet Block](https://github.com/kendraio/kendraio-app/blob/main/docs/workflow/blocks/wallet.rst)
+- [Wallet Block](https://github.com/kendraio/kendraio-app/blob/main/docs/workflow/blocks/wallet.rst)
 
 **Example flows**
 
--   Check out our Player:
-<https://app.kendra.io/player/all>
+- Check out our Player:
+  <https://app.kendra.io/player/all>
 
--   Wallet Block demo:
-<https://app.kendra.io/dsp1/walletArray>
+- Wallet Block demo:
+  <https://app.kendra.io/distributor/walletArray>
 
--   Statistics using anonymous analytics: 
-<https://app.kendra.io/player/stats>
+- Statistics using anonymous analytics:
+  <https://app.kendra.io/player/stats>
 
 **Components:**
 
--   Web Money block: 
-<https://github.com/kendraio/kendraio-app/blob/main/src/app/blocks/web-money/web-money.component.ts>
+- Web Money block:
+  <https://github.com/kendraio/kendraio-app/blob/main/src/app/blocks/web-money/web-money.component.ts>
 
--   Wallet block:
-https://github.com/kendraio/kendraio-app/blob/main/src/app/blocks/wallet/wallet.component.ts
+- Wallet block:
+  https://github.com/kendraio/kendraio-app/blob/main/src/app/blocks/wallet/wallet.component.ts
 
--   Uphold service library:
-https://github.com/kendraio/kendraio-app/blob/main/src/app/_shared/services/uphold_service.ts
+- Uphold service library:
+  https://github.com/kendraio/kendraio-app/blob/main/src/app/_shared/services/uphold_service.ts

docs/workflow/blocks/actions.rst

@@ -37,14 +37,14 @@ Supported properties
   If `enabledGetter` is set to `false` the automatic property will be then shown as `"enabled": false`.
   - **valueGetters** (string) - A value that will be pass as context to whichever action is being executed. 
   This is a JMESPath mapping.
-  - **blocks** (array) - the list of Flow items to run when this button is pressed.
+  - **blocks** (array) - the list of workflow items to run when this button is pressed.
 
 Example
 -------
 
 This example shows two buttons. The first one dispatches an asynchronous command using the
 :doc:`Event Dispatch <dispatch>` bloc, the second one does nothing, but includes an ``init``
-block in order to start the inner Flow so that it runs and signals completion to the outer Flow.
+block in order to start the inner workflow so that it runs and signals completion to the outer workflow.
 
 .. code-block:: json
   {

docs/workflow/blocks/adapter_info.rst

@@ -1,20 +1,20 @@
 Adapter Info
 ============
 
-The Adapter info block is used to read adapter configurations within Flows
+The Adapter info block is used to read adapter configurations within workflows
 and get information on which adapters are enabled.
 
 There are two versions of this block ``adapter-list`` produces a full list of
 adapter metadata, whereas ``adapter-info`` is used to query for information
 on a specific adapter. The block config should include ``adapterName`` to
 specify which adapter info is loaded, or ``adapterNameGetter`` can be set
 using a JMES Path expression to query the name of the adapter to fetch from
-either the block input data or Flow context.
+either the block input data or workflow context.
 
 Example
 -------
 
-This example is taken from one of the core Flows where the adapter
+This example is taken from one of the core workflows where the adapter
 info block is used to create a list of all the enabled adapters:
 
 .. code-block:: json
@@ -23,7 +23,7 @@ info block is used to create a list of all the enabled adapters:
       "type": "adapter-list"
     }
 
-This example is also from a core Flow, and shows how to load
+This example is also from a core workflow, and shows how to load
 information about a specific adapter:
 
 .. code-block:: json
@@ -38,7 +38,7 @@ Packaged Adapters
 -----------------
 
 To access all flows and config related to an adapter, it is possible to request the entire "packaged adapter". 
-With this option set, the adapter will include an "attachments" section, containing the source of all Flows, 
+With this option set, the adapter will include an "attachments" section, containing the source of all flows, 
 schemas, forms and config.
 
 .. code-block:: json

docs/workflow/blocks/batch.rst

@@ -1,8 +1,8 @@
 Batch Process
 =============
 
-Run the specified Flow for every item in a list. This block expects an array (list) of items to be passed in as data.
-It will run the embedded Flow for every item in the list, collect the results, and then output the list of results once all the tasks have completed.
+Run the specified workflow for every item in a list. This block expects an array (list) of items to be passed in as data.
+It will run the embedded workflow for every item in the list, collect the results, and then output the list of results once all the tasks have completed.
 
 Default config
 --------------
@@ -17,8 +17,8 @@ Default config
 Supported properties
 --------------------
 
-- **blocks** (array) - the Flow (list of blocks) to run for each item in the input data list.
-- **flex** (boolean) (default = false) - apply a flex layout to the batch Flow outputs.
+- **blocks** (array) - the workflow (list of blocks) to run for each item in the input data list.
+- **flex** (boolean) (default = false) - apply a flex layout to the batch workflow outputs.
 
 
 Examples
@@ -65,4 +65,4 @@ A common way to use the Batch Block is in conjunction with the Cards Block. When
             ]
         }
     ]
-  }
+  }

docs/workflow/blocks/card.rst

@@ -16,4 +16,4 @@ Default config
 Supported properties
 --------------------
 
-- **blocks** - the list of Flow Blocks that make up the display within the card
+- **blocks** - the list of workflow blocks that make up the display within the card

docs/workflow/blocks/dialog.rst

@@ -1,7 +1,7 @@
 Dialog
 ======
 
-Launch a modal dialog in which to run an embedded Flow.
+Launch a modal dialog in which to run an embedded workflow.
 
 Default config
 --------------
@@ -13,8 +13,8 @@ Default config
       "blocks": []
     }
 
-**NB:** The modal dialog will close as soon as the inner Flow completes.
-Therefore you probably want to include at least one Flow item that requires interaction
+**NB:** The modal dialog will close as soon as the inner workflow completes.
+Therefore you probably want to include at least one workflow item that requires interaction
 from the user, for example, ``actions`` buttons or a ``form``.
 
 Example

docs/workflow/blocks/dispatch.rst

@@ -16,8 +16,8 @@ Default config
 Usage
 -----
 
-This block is only really useful by core Flows, as adapter Flows
-are not yet able to register asynchronous Flows to run in response to events.
+This block is only really useful by core workflows, as adapter workflows
+are not yet able to register asynchronous workflows to run in response to events.
 
 To track development of this feature, see this issue:
 https://github.com/kendraio/kendraio-app/issues/53

docs/workflow/blocks/form.rst

@@ -24,7 +24,7 @@ Supported properties
 - **adapter** and **formId**: if these two properties are provided they are used to fetch the JSON schema and UI Schema from the adapter config repository.
 - **label** (default = “Submit): customise the label displayed on the submit button
 - **hasSubmit** (default = true): this allows you to remove the submit button from the form. If this is set to true the submit button is not displayed and the form will output all changes.
-- **debounceTime** (default = 400): the number of milliseconds to debounce form output when not using a submit button. Multiple changes within this time will be ignored, and only the last change is emitted. This is a useful option to prevent unnecessary execution of multiple tasks within the Flow, for example if the form feeds into a HTTP block to pull data from an API (such as in an autocomplete) then the debounce will limit the number of requests that are sent while the user is entering input.
+- **debounceTime** (default = 400): the number of milliseconds to debounce form output when not using a submit button. Multiple changes within this time will be ignored, and only the last change is emitted. This is a useful option to prevent unnecessary execution of multiple tasks within the workflow, for example if the form feeds into a HTTP block to pull data from an API (such as in an autocomplete) then the debounce will limit the number of requests that are sent while the user is entering input.
 - **emitOnInit** (boolean) (default = false): enable this to emit the form values when the block is initialised. This is useful if you need to pass on default values.
 - **schemaGetter**: Form schemas can be made dynamic by providing a set of blocks that will generate a schema. 
 - **contextErrorKey** (default = null): the key used to store the error message in the context. This is useful if you want to display the error message in a different block.
@@ -40,16 +40,16 @@ uiSchema properties
 - **blocks**: The blocks to nest in the form field. This should be an array, even if it is a single item.
 - **type**: The type of block to be used.
 
-Important notes on creating Flows with forms
+Important notes on creating flows with forms
 --------------------------------------------
 
-When a form is submitted, it will trigger the execution of the next block in the Flow, passing through any new data.
-Blocks will continue to pass processing through the Flow, until a block emits the same data as it did previously - 
-at which point the change detection will stop the Flow. 
+When a form is submitted, it will trigger the execution of the next block in the flow, passing through any new data.
+Blocks will continue to pass processing through the flow, until a block emits the same data as it did previously - 
+at which point the change detection will stop the flow. 
 
-If you are creating Flows that need to respond to new data from the forms, you will need to pay attention to the blocks
+If you are creating flows that need to respond to new data from the forms, you will need to pay attention to the blocks
 that follow the form, making sure that every block emits changes to that processing continues. If you have blocks that are 
-not dependent on the form, then it is best to place them before the form in the Flow. 
+not dependent on the form, then it is best to place them before the form in the flow. 
 
 
 

docs/workflow/blocks/gosub.rst

@@ -1,15 +1,15 @@
 Gosub
 =====
 
-Embedded a Flow within a Flow.
+Embedded a workflow within a workflow.
 
-This allows composition of larger building blocks to create Flows that
+This allows composition of larger building blocks to create workflows that
 are easier to manage, and DRY (don't repeat yourself).
 
 Typical use-cases for this are creating custom form widgets that can
 be referenced from a form's ``uiSchema``. Or, creating dashboards
-that are made up of multiple other Flows combined with a ``multi``
-multiplex Flow block.
+that are made up of multiple other workflows combined with a ``multi``
+multiplex workflow block.
 
 
 

docs/workflow/blocks/grid.rst

@@ -64,8 +64,8 @@ Example
 Advanced features
 -----------------
 
-Adding ``"cellRenderer": "workflowRenderer"`` to a column allows to embed Flow within a cell of the table.
-The ``cellRendererParams`` should include ``blocks`` as an array of Flow tasks to be added to the cell. Examples of
+Adding ``"cellRenderer": "workflowRenderer"`` to a column allows to embed workflow within a cell of the table.
+The ``cellRendererParams`` should include ``blocks`` as an array of workflow tasks to be added to the cell. Examples of
 use include adding an "Operations" column, using the "actions" task within the cell to add a list of buttons to operate
 on the data from that row. The cell will be passed in data from that row of the grid only.
 
@@ -74,8 +74,8 @@ Examples
 
 This example shows some advanced grid features, such as customisation of the
 pagination, multiple row selection, the addition of a selectable checkbox column,
-and the use of the "workflow renderer" to embed another Flow within
-the grid cells. For example, the Flow renderer is useful for adding edit buttons
+and the use of the "workflow renderer" to embed another workflow within
+the grid cells. For example, the workflow renderer is useful for adding edit buttons
 to a content administration table.
 
 .. code-block:: json

docs/workflow/blocks/init.rst

@@ -1,7 +1,7 @@
 Initialisation
 ==============
 
-Initialise Flow processing on page load.
+Initialise workflow processing on page load.
 
 Default config
 --------------

docs/workflow/blocks/launch_block.rst

@@ -1,13 +1,9 @@
 Launch
 ======
 
-<<<<<<< HEAD
 Useful to jump to a different Flow. This block is not available to be added to a flow directly, but is instead for use from within other blocks.
 
 If you want to jump to a different Flow from a button the :doc:`Link Action Block <link_action_block>`, allows opening Flows in a new tab or window as an alternative to an :doc:`Actions block button <actions>` being used with a Launch block.
-=======
-Jump to a new Flow. This block is not available to be added to a Flow directly, but is instead for use from within other blocks. 
->>>>>>> e5a07579 (Convert "Workflow" text to "Flow" (#451))
 
 Default config
 --------------
@@ -23,8 +19,8 @@ Default config
 Supported properties
 --------------------
 
-- **adapter** - The adapter of the Flow to launch
-- **workflowId** - The Flow to launch
+- **adapter** - The adapter of the flow to launch
+- **workflowId** - The flow to launch
 - **valueGetters** - An onbject containing JMESPath to evaluate for adapter and workflowId.
 - **context** - Data that will be passed to the flow to launch
 

docs/workflow/cloud.rst

@@ -1,8 +1,8 @@
-Flow Cloud
+Workflow Cloud
 ==============
 
-Flows can be downloaded from the Flow Cloud.
+Workflows can be downloaded from the Workflow Cloud.
 
-These Flows are not specific to any adapter.
+These workflows are not specific to any adapter.
 
 This section is under active development and likely to change.

docs/workflow/implementation.rst

@@ -1,12 +1,8 @@
-How Flows get executed
+How flows get executed
 ======================
 
 Flows are implemented using Angular's built-in execution chaining. 
-<<<<<<< HEAD
 While this simplifies the whole process of running workflows, it does 
-=======
-While this simplifies the whole process of running Flows, it does 
->>>>>>> e5a07579 (Convert "Workflow" text to "Flow" (#451))
 introduce some challenges - many of which can be overcome by understanding
 a little about how flows are run, and in particular, the way change detection
 works. 
@@ -15,24 +11,24 @@ works.
 
 |step1|   
 
-The first time a Flow is run, each of the blocks is initialised, but 
+The first time a flow is run, each of the blocks is initialised, but 
 does not receive any data. This is the "firstRun", and some blocks will have an option to skip execution on this step.
 
 
 |step2|
 
-Processing then begins a second time, and this time round, the output from 
-a block is passed to the next block in the Flow. 
+Processing then begins a second time,and this time round, the output from 
+a block is passed to the next block in the flow. 
 
 |step3|
 
 Many blocks are asynchronous. This means that they will have two different outputs to 
 pass on to the block that follows them. The first output will essentially be blank. No actual processing 
 has happened yet, as the internal work has been "forked" off. This blank output will pass through the 
-Flow once, triggering every block to run. 
+flow once, triggering every block to run. 
 
 Once the asynchronous block has completed it's work, it will sent it's output to the next block. This will
-then trigger the next processing of the Flow. 
+then trigger the next processing of the flow. 
 
 |step4|
 
@@ -45,7 +41,7 @@ will need to change, and so stops processing the chain.
 
 |step5|
 
-When building Flows, we need to be aware of this change
+When building flows, we need to be aware of this change
 detection behaviour. If any of our blocks, mapping blocks 
 in particular, emit a result that is unchanged from a 
 previous run, processing will stop. 
@@ -54,13 +50,13 @@ previous run, processing will stop.
 Implications when working with forms
 ------------------------------------
 
-This is particularly important if a Flow contains a form that 
+This is particularly important if a flow contains a form that 
 gathers input from the user. When a form is submitted, the 
-next block in the Flow is triggered and passed the data from
+next block in the flow is triggered and passed the data from
 the form. This will then pass on execution to it's child - until 
 any block emits the same output as it did before the form 
 was submitted. The moment output does not change, 
-processing will stop and no more blocks in the Flow will run. 
+processing will stop and no more blocks in the flow will run. 
 
 
 

docs/workflow/intro.rst

@@ -5,21 +5,12 @@ Overview
 --------
 
 Flows are created by plugging together various reusable blocks of functionality.
-<<<<<<< HEAD
 A Flow is made from multiple blocks that connect together. A task is a running instance of a Flow.
 Flows can be nested inside other Flows.
 Thus, tasks are nested too, and a running task may contain multiple tasks within it.
 
 The available “blocks” of reusable functionality are documented below.
 The Flow builder in the app lets you create and customise Flows,
-=======
-A Flow is a list of Flow items (or blocks). A task is a running instance of a Flow.
-Flow definitions can be nested, as some Flow item blocks contain embedded Flows.
-Thus, tasks are nested too, and a running task may contain multiple tasks within it.
-
-The available “blocks” of reusable functionality are documented below.
-The Flow builder within the app lets you create and customise Flows,
->>>>>>> e5a07579 (Convert "Workflow" text to "Flow" (#451))
 load existing Flows from adapters, and generate links to share Flows you have created.
 
 Block Metadata & Comments