diff --git a/docs/development_suite/monitoring/resources/custom-resources.md b/docs/development_suite/monitoring/resources/custom-resources.md index ffaa3aec6d..76ee079bf6 100644 --- a/docs/development_suite/monitoring/resources/custom-resources.md +++ b/docs/development_suite/monitoring/resources/custom-resources.md @@ -2,7 +2,7 @@ id: custom-resources title: Monitor your Custom Kubernetes Resources sidebar_label: Monitor your Custom Kubernetes Resources -slug: "/development_suite/monitoring/resources/jobs" +slug: "/development_suite/monitoring/resources/custom-resources" --- @@ -12,6 +12,8 @@ If deployed, the information on the [Custom Resources](/console/design-your-proj If you created one or more Custom Kubernetes Resource from a marketplace template **prior** to Console release v13.3.0, the resources **will not be visible by default**. Please ensure to [update your resource](/marketplace/add_to_marketplace/add_item_by_type/add_custom_resource.md#update-a-custom-resource-to-the-console-v1330) version via [miactl](/cli/miactl/10_overview.md) to one that has the properties `resourceId` and `type` correctly set in the `runtime` object field of its definition, otherwise the Custom Kubernetes Resources won't be visible in the section even if the resource is active. + +Furthermore, the resources created **from scratch** will not be visible in the Runtime area. We will introduce the support in future versions of the Console. ::: diff --git a/docs/microfrontend-composer/external-components/bundling.md b/docs/microfrontend-composer/external-components/bundling.md index 7ba927ab42..533f11f3d7 100644 --- a/docs/microfrontend-composer/external-components/bundling.md +++ b/docs/microfrontend-composer/external-components/bundling.md @@ -1,13 +1,13 @@ --- id: bundling -title: Bundling your webcomponents with vite +title: Bundling your Web Components with vite sidebar_label: Bundling sidebar_position: 30 --- -The aim of this section is to highlight some features we found useful to bundle webcomponents together. +The aim of this section is to highlight some features we found useful to bundle Web Components together. -Let's say we have a bunch of webcomponents such as +Let's say we have a bunch of Web Components such as ```text ├── my-button @@ -23,7 +23,7 @@ Let's say we have a bunch of webcomponents such as | ``` -The most important thing to remember is that webcomponent definitions must appear once and they must not repeat themself even accidentally (the bundler might mess up with the tree of dependencies). +The most important thing to remember is that Web Component definitions must appear once and they must not repeat themself even accidentally (the bundler might mess up with the tree of dependencies). Another point of attention must be the desired output: whether the library will be consumed by browsers only or could be made available to Node.js environments as development resource, say by publishing an npm library. @@ -109,11 +109,11 @@ export default defineConfig({ }) ``` -Be aware that runtime loading of webcomponents is a key factor here. The browser `window` won't be able to follow dynamic imports in order to wait page `onload` event, which means that loading multiple webcomponents from different bundles might make them appear at different times. A consistent visualization is instead guaranteed when the components are loaded together, at least to a further degree. +Be aware that runtime loading of Web Components is a key factor here. The browser `window` won't be able to follow dynamic imports in order to wait page `onload` event, which means that loading multiple Web Components from different bundles might make them appear at different times. A consistent visualization is instead guaranteed when the components are loaded together, at least to a further degree. -This remark does not rule out separate bundles. For instance `micro-lc` is bundled separately with respect to its loading webcomponent, which by default shows spinning hexagons until `micro-lc` fires an `onload` event. `mlc-loading-animation` loads first and is safe to assume won't need `micro-lc` to be loaded to start its work. +This remark does not rule out separate bundles. For instance `micro-lc` is bundled separately with respect to its loading Web Component, which by default shows spinning hexagons until `micro-lc` fires an `onload` event. `mlc-loading-animation` loads first and is safe to assume won't need `micro-lc` to be loaded to start its work. -A components library providing buttons, tables, forms, is definitively an example of a set of webcomponents which must be bundled together: +A components library providing buttons, tables, forms, is definitively an example of a set of Web Components which must be bundled together: 1. they load together avoiding weird flashes 2. they reuse chunks of code like stylesheets diff --git a/docs/microfrontend-composer/external-components/manifest.md b/docs/microfrontend-composer/external-components/manifest.md index 126e847591..b2a1d92561 100644 --- a/docs/microfrontend-composer/external-components/manifest.md +++ b/docs/microfrontend-composer/external-components/manifest.md @@ -1,42 +1,31 @@ --- id: manifest -title: The Webcomponent Manifest +title: The Web Component Manifest sidebar_label: Manifest sidebar_position: 20 --- -Any webcomponent is or aims to be: +Any Web Component is or aims to be: 1. an HTML tag 2. a CSS encapsulated environment 3. a JS business logic unit -As HTML tag, a custom webcomponent has `attributes` and `properties`. Moreover a pair `attribute` and `property` can be coupled by reflecting changes: a change on the former is mirrored on the latter, and viceversa. +As HTML tag, a custom Web Component has `attributes` and `properties`. Moreover a pair `attribute` and `property` can be coupled by reflecting changes: a change on the former is mirrored on the latter, and viceversa. ## Basics -The Configurator layout section queries the webcomponents to discover their properties/attributes using a static getter promise called a _Manifest_. +The Configurator layout section queries the Web Components to discover their metadata and their properties/attributes using a static getter promise called a _Manifest_. + +The `__manifest` static getter must return a JavaScript object containing information on the component metadata, properties and attributes, and API mocks. :::tip -You can use the [JSON schema](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/manifest.schema.json) to check your components manifests. +You can use the [JSON schema](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/manifest.schema.json) to get information on the supported properties and to check your components manifests. ::: -The `__manifest` static getter must return a JavaScript object that has a key `type` which must be `object` (to be JSON schema compatible) and a map of `properties`. - -```typescript -const manifest = { - type: 'object', - properties: { - // list of properties - } -} -``` - -A custom button might look like: - -```typescript -// my-button.ts +As an example, consider the following custom button component +```typescript title=my-button.ts import { LitElement } from 'lit' class MyButton extends LitElement { @@ -48,14 +37,13 @@ class MyButton extends LitElement { } ``` -and thus will instruct the Configurator preview section with the following manifest +The component exposes the static getter `__manifest` thus instructing the Configurator preview section with the following manifest -```typescript -// manifest.ts +```typescript title=manifest.ts import type { Manifest } from '@micro-lc/compose-toolkit' const manifest = { - type: 'object', + label: 'My awesome button', properties: { hidden: { type: 'boolean' @@ -66,9 +54,11 @@ const manifest = { export default manifest ``` -In the outlined example, the Configurator layout section will provide its configuration form with a boolean toggle for the `hidden` property. +## Attribute and properties + +The component attributes and properties can be described using the `properties` key of the manifest, which should be an object mapping the component properties to a JSON schema. -Types can be **almost** anything that JSON schema provides: +Properties types can be **almost** anything that JSON schema provides: 1. `boolean` 2. `string` @@ -85,13 +75,11 @@ Complex properties such as objects and arrays are also handled in a `no-code` fa The most basic visualization for an `object` without a schema is an IDE-like editor, with basic JSON validation capabilities. Likewise an array has a `no-code` item selector, which again, without schema will spawn an IDE-like editor for each one of its items. -The owner/developer of custom webcomponents can enforce `no-code` configurability by nesting the component manifest. +The owner/developer of custom Web Components can enforce `no-code` configurability by nesting the component manifest. For instance: -```typescript -// my-button.ts - +```typescript title=my-button.ts import { LitElement } from 'lit' interface Action { @@ -110,12 +98,10 @@ class MyButton extends LitElement { can be described by the following manifest -```typescript -// manifest.ts +```typescript title=manifest.ts import type { Manifest } from '@micro-lc/compose-toolkit' const manifest: Manifest = { - type: 'object', properties: { action: { type: 'object', @@ -132,17 +118,15 @@ export default manifest Despite the `action` being an object, the Configurator layout section will spawn a modal (which can have potentially infinite levels of nesting) to configure `type` as a string with at most 2 fixed values and `url` as a string. -## Mia's Configuration Advanced +### Mia's Configuration Advanced -The Webcomponent manifest is a superset of a compliant draft-07 JSON schema. The Configurator guarantees to display a `no-code` comfortable version of each property. +The Web Component manifest is a superset of a compliant draft-07 JSON schema. The Configurator guarantees to display a `no-code` comfortable version of each property. -Beside this specification, Configurator can enforce some extra logic using a special property, available to any webcomponent property or nested property: `__mia_configuration`. +Beside this specification, Configurator can enforce some extra logic using a special property, available to any Web Component property or nested property: `__mia_configuration`. Let's consider a custom button -```typescript -// my-button.ts - +```typescript title=my-button.ts import { LitElement } from 'lit' class MyButton extends LitElement { @@ -156,12 +140,10 @@ class MyButton extends LitElement { with manifest -```typescript -// manifest.ts +```typescript title=manifest.ts import type { Manifest } from '@micro-lc/compose-toolkit' const manifest = { - type: 'object', properties: { hidden: { type: 'boolean' @@ -231,16 +213,14 @@ export interface MiaConfiguration { } ``` -### The `oneOfGuard` key +#### The `oneOfGuard` key Suppose your property is a JSON `oneOf` an there's a guard key which allows to distinguish non-overlapping types. For instance: -```typescript -// manifest.ts +```typescript title=manifest.ts import type { Manifest } from '@micro-lc/compose-toolkit' const manifest = { - type: 'object', properties: { action: { type: 'object', @@ -273,7 +253,7 @@ By using `oneOfGuard` set to `type` Configurator layout section is able to provi If the user selects `http-post` then 2 string input will appear in order to configure `url` and `payload`, otherwise an IDE-like editor will allow to type directly the `payload` property since no schema was provided. -### The `schema-hint` key +#### The `schema-hint` key Configurator provides some types that are well known and often used in order to avoid writing down a repeating JSON schema multiple times. @@ -290,7 +270,7 @@ Configurator provides some types that are well known and often used in order to projection, or a Fast Data Single View. 10. A `micro-lc/applications` is the list of currently configured applications in the Configurator initial section. -### The `shared-key` key +#### The `shared-key` key JSON schema supports referencing of property definitions. Despite not being a fixed pattern there's a recommendation for draft-07 which suggests to use the key `definitions` at the first level of your JSON configuration. In the most recent drafts it will be substituted by the `$defs` keyword. diff --git a/docs/microfrontend-composer/external-components/overview.md b/docs/microfrontend-composer/external-components/overview.md index 82af3de709..91a80b0de6 100644 --- a/docs/microfrontend-composer/external-components/overview.md +++ b/docs/microfrontend-composer/external-components/overview.md @@ -5,7 +5,7 @@ sidebar_label: Overview sidebar_position: 10 --- -The Configurator layout/advanced sections provide tools to visualize [composable pages](/microfrontend-composer/composer/20_compose_pages.md) which are made of webcomponents. For instance, the Configurator [main layout](/microfrontend-composer/composer/10_structure.md#layout) is a web page build with webcomponents. +The Configurator layout/advanced sections provide tools to visualize [composable pages](/microfrontend-composer/composer/20_compose_pages.md) which are made of Web Components. For instance, the Configurator [main layout](/microfrontend-composer/composer/10_structure.md#layout) is a web page build with Web Components. Components usually are provided by JavaScript libraries like: @@ -22,7 +22,7 @@ The `sources` field has its own [JSON schema](https://raw.githubusercontent.com/ for further references, check out the [micro-lc documentation](https://micro-lc.io/docs/guides/applications/compose#plugin-configuration) on composable page `sources`. -The only limitation, left to the user to check, is not to define the same webcomponent twice or more from different libraries. This might happen when different composable pages have different versions of the same library. The Configurator will not complain but errors might arise when the final website is deployed. +The only limitation, left to the user to check, is not to define the same Web Component twice or more from different libraries. This might happen when different composable pages have different versions of the same library. The Configurator will not complain but errors might arise when the final website is deployed. The default configuration of the Configurator section, once the [application](/runtime_suite_applications/microfrontend-composer-toolkit/10_overview.md) is added to your Console project, on the branch you're currently working on, is preset to use the components library [@micro-lc/bk-web-components](https://www.jsdelivr.com/package/npm/@micro-lc/bk-web-components), which is well-suited to visualize data through tables, cards and galleries. @@ -153,21 +153,21 @@ The following actions need to be addressed: ## No/Low-code Components Configuration -```tip -To view your external components, you may need to [configure](/microfrontend-composer/composer/30_configurator_settings.md#source-maps) the correct reverse proxying in the Configurator Service Worker . -``` +:::tip +To view your external components, you may need to [configure](/microfrontend-composer/composer/30_configurator_settings.md#source-maps) the correct reverse proxying in the Configurator Service Worker. +::: -Any HTML tag (native or custom) is eligible to be configured in the `low-code` configuration section, which is label by the tab `Advanced`. +Any HTML tag (native or custom) is eligible to be configured in the `low-code` configuration section, which is label by the tab _Advanced_. -Any custom webcomponent must be defined in at most one of the `sources` entries to be displayed in the preview otherwise it will not render anything beside an empty tag. +Any custom Web Component must be defined in at most one of the `sources` entries to be displayed in the preview otherwise it will not render anything beside an empty tag. -The absence of a custom webcomponent definition does not break the preview of a compose page, but somewhat limits the user experience of the whole section. +The absence of a custom Web Component definition does not break the preview of a compose page, but somewhat limits the user experience of the whole section. -Any `low-code` configuration can be performed in the `Advanced` section in the form of plain JSON editing. Such editing is guided by the basic schema of a [compose page](https://github.com/micro-lc/micro-lc/blob/main/packages/interfaces/schemas/v2/plugin.schema.json), and is embedded in the editing IDE of the `Advanced` section. +Any `low-code` configuration can be performed in the _Advanced_ section in the form of plain JSON editing. Such editing is guided by the basic schema of a [compose page](https://github.com/micro-lc/micro-lc/blob/main/packages/interfaces/schemas/v2/plugin.schema.json), and is embedded in the editing IDE of the _Advanced_ section. -`no-code` section, labelled by the tab `Layout` is aware of any defined custom webcomponent. To configure a webcomponent using the `no-code` section, the component itself must provide a dynamically imported manifest which describe itself to the configurator and allows the spawning of forms and modals apt to the task of filling webcomponent properties according to the proper type and schema validation. +The `no-code` section, labelled by the tab _Layout_, is aware of any defined custom Web Component. To configure a Web Component using the `no-code` section, the component itself must provide a dynamically imported manifest which describe itself to the configurator and allows the spawning of forms and modals apt to the task of filling Web Component properties according to the proper type and schema validation. -There are different layers of integration for custom webcomponents with the `no-code` Configurator section: +There are different layers of integration for custom Web Components with the `no-code` Configurator section: 1. editing properties using forms and modals 2. open/show when selected on the [left components list](/microfrontend-composer/composer/10_structure.md#layout) @@ -175,7 +175,7 @@ There are different layers of integration for custom webcomponents with the `no- ### No-Code Properties Editing: `__manifest` -A webcomponent must explain to the configurator how it can be configured. Roughly any webcomponent scaffolding looks like: +A Web Component must explain to the configurator how it can be configured. Roughly any Web Component scaffolding looks like: ```typescript class MyCustomComponent extends HTMLElement { @@ -185,7 +185,7 @@ class MyCustomComponent extends HTMLElement { } ``` -A webcomponent which exposes a static getter `__manifest` as per the following snippet: +A Web Component which exposes a static getter `__manifest` as per the following snippet: ```typescript import type { Manifest } from '@micro-lc/compose-toolkit' @@ -208,21 +208,21 @@ static get __manifest(): Promise { } ``` -The **manifest** file, after JSON-stringify process, must validate an [extension](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/template.schema.json) of a draft-07 [JSON schema](https://json-schema.org) where the `type` is always `object` and the field `properties` is an object listing the configurable properties of the custom webcomponent. +The **manifest** file, after JSON-stringify process, must validate an [extension](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/template.schema.json) of a draft-07 [JSON schema](https://json-schema.org) where the `type` is always `object` and the field `properties` is an object listing the configurable properties of the custom Web Component. -Any object property has also a _special_ key `__mia_configuration` which allows to customize labels in the Configurator `Layout` section. The `__mia_configuration` key is not mandatory and does not affect the no-code configuration features on custom webcomponents. +Any object property has also a _special_ key `__mia_configuration` which allows to customize labels in the Configurator _Layout_ section. The `__mia_configuration` key is not mandatory and does not affect the no-code configuration features on custom Web Components. -Check out [the webcomponent manifest](/microfrontend-composer/external-components/manifest.md) for further details. +Check out [the Web Component manifest](/microfrontend-composer/external-components/manifest.md) for further details. ### Open/Show On Select: `__focus_handler`, `__unfocus_handler` -When a custom webcomponent has an open/close, hidden/shown behavior, like a modal or a collapsible drawer, the Configurator previews must be informed on how to make such item to appear and disappear. Considering the case of a modal, its initial state could be `closed`. A user interaction is often required to trigger its opening. +When a custom Web Component has an open/close, hidden/shown behavior, like a modal or a collapsible drawer, the Configurator previews must be informed on how to make such item to appear and disappear. Considering the case of a modal, its initial state could be `closed`. A user interaction is often required to trigger its opening. -When clicking the webcomponent label on the left menu list corresponding to the modal, the presence of a `__focus_handler` function allows to mock the user action needed to open the component real context. +When clicking the Web Component label on the left menu list corresponding to the modal, the presence of a `__focus_handler` function allows to mock the user action needed to open the component real context. Once left menu selection is over, an `__unfocus_handler` is called to perform cleanup operations. -The webcomponent must implement the following interface: +The Web Component must implement the following interface: ```typescript @@ -242,9 +242,31 @@ class MyCustomComponent extends HTMLElement implements FocusableComponent { ``` +### List custom components in Components Explorer + +The [Components Explorer](/microfrontend-composer/composer/10_structure.md#components-explorer) section of the configurator is instructed to try and list all the Web Components libraries that appear in the Composer `sources`. + +For a library to be visualized in the explorer, its entry point has to declare a **default export** with the following type: + +```typescript +type LibraryMeta = { + /** Name of the library */ + libraryName: string + + /** List of the library Web Component tags */ + components: string[] +} +``` + +:::tip +If you are bundling your library with Vite, make sure to set the property `build.rollupOptions.preserveEntrySignatures` to `allow-extension` in your Vite config file. +::: + +The explorer will list all the components in library meta and will show for each of them information taken from their [manifests](/microfrontend-composer/external-components/manifest.md) (if present). + ## Bundling -As previously mentioned, webcomponents are served to the Configurator via library bundles. The recommended way to proceed is: +As previously mentioned, Web Components are served to the Configurator via library bundles. The recommended way to proceed is: 1. either an ESM bundle @@ -252,11 +274,11 @@ As previously mentioned, webcomponents are served to the Configurator via librar Due to the nature of [manifests](/microfrontend-composer/external-components/manifest.md) and their retrieval dynamic policy, the ESM option is more than recommended. -Webcomponents can be build with any library (lit, stencil, and so on...) or going fully native. Examples with `lit` are provided [`@micro-lc/layout`](https://github.com/@micro-lc/layout) library while `micro-lc` [itself](https://github.com/micro-lc/micro-lc/main/packages/orchestrator/src/web-component/micro-lc.ts) is an example of a native webcomponent. +Web Components can be build with any library (lit, stencil, and so on...) or going fully native. Examples with `lit` are provided [`@micro-lc/layout`](https://github.com/@micro-lc/layout) library while `micro-lc` [itself](https://github.com/micro-lc/micro-lc/main/packages/orchestrator/src/web-component/micro-lc.ts) is an example of a native Web Component. -`vite` turned out to be very natural and comfortable tool to bundle and inspect webcomponents by embedding them in a test html page. The bundler, which is `rollup` provides the capabilities to: +`vite` turned out to be very natural and comfortable tool to bundle and inspect Web Components by embedding them in a test html page. The bundler, which is `rollup` provides the capabilities to: -1. select which sources to use as entry points. For instance, webcomponents can be bundled separately or all together in a unique bundle. Your use case is the only reference on whether to go the former or the latter way; +1. select which sources to use as entry points. For instance, Web Components can be bundled separately or all together in a unique bundle. Your use case is the only reference on whether to go the former or the latter way; 2. separate external sources, like manifests; 3. add external assets like images, fonts and so on... diff --git a/docs/release-notes/v13.3.0.md b/docs/release-notes/v13.3.0.md index 032393b807..805b7dfda3 100644 --- a/docs/release-notes/v13.3.0.md +++ b/docs/release-notes/v13.3.0.md @@ -17,15 +17,7 @@ export const Highlight = ({children, color}) => ( ); -_October 24th, 2024_ - -:::info -Mia-Platform Console v13.3.0 - Fall Release is **now in Preview** and will be generally available on November 21st. - -Console SaaS users can try out v13.3.0 - Fall Release latest improvements in Preview! Open a Service Request to ask for the creation of a sandbox Company in case you do not have access to any Company. - -For self-hosted installations, please read the [following guidelines](#how-to-update-your-console). -::: +_November 18th, 2024_ ## Support to all Infrastructure Resources in Design @@ -167,5 +159,5 @@ In this minor version, we’ve added a new feature to the `FormModal` component. ## How to update your Console -For self-hosted installations, please head to the [self hosted upgrade guide](/infrastructure/self-hosted/installation-chart/100_how-to-upgrade.md) or contact your Mia-Platform referent and upgrade to _Console Helm Chart_ `v13.7.5-beta.1`. +For self-hosted installations, please head to the [self hosted upgrade guide](/infrastructure/self-hosted/installation-chart/100_how-to-upgrade.md) or contact your Mia-Platform referent and upgrade to _Console Helm Chart_ `v13.7.5`. diff --git a/docs/runtime_suite/auth0-client/20_configuration.md b/docs/runtime_suite/auth0-client/20_configuration.md index 60c83732a4..dd95e7bf4b 100644 --- a/docs/runtime_suite/auth0-client/20_configuration.md +++ b/docs/runtime_suite/auth0-client/20_configuration.md @@ -25,6 +25,8 @@ The Auth0-Client service accepts the following environment variables: - __REDIS_USERNAME__: defines the redis username to be used for authentication - __REDIS_PASSWORD__: defines the redis password to be used for authentication - __REDIS_HOSTS__ (__required__): defines the redis hosts +- __REDIS_TLS__ (__default: `false`__): when `true`, enables the TLS connection to Redis +- __REDIS_TLS_CACERT__: defines the path to the Redis server CA, if not public (this is effective only if `REDIS_TLS` is set to `true`) - __ORIGINAL_PROTOCOL_HEADER__ (__required__): defines the original protocol header - __SERVICE_CONFIG_FILE_NAME__ (__required__): defines the service config name - __SERVICE_CONFIG_PATH__ (__required__): defines the service config path diff --git a/docs/runtime_suite/auth0-client/changelog.md b/docs/runtime_suite/auth0-client/changelog.md index 904a2fef26..8004a004ac 100644 --- a/docs/runtime_suite/auth0-client/changelog.md +++ b/docs/runtime_suite/auth0-client/changelog.md @@ -15,6 +15,18 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). +## 3.7.1 - 07-11-2024 + +### Fixed + +- logout redirect when a query params set in the redirect path + +## 3.7.0 - 30-10-2024 + +### Added + +- add TLS connection support for Redis in normal and sentinel mode + ## 3.6.0 - 26-02-2024 ### Added diff --git a/docs/runtime_suite/care-kit/20_components/150_ck_roles_and_permissions.md b/docs/runtime_suite/care-kit/20_components/150_ck_roles_and_permissions.md new file mode 100644 index 0000000000..4d3c8280ea --- /dev/null +++ b/docs/runtime_suite/care-kit/20_components/150_ck_roles_and_permissions.md @@ -0,0 +1,169 @@ +--- +id: ck_roles_and_permissions +title: ck-roles-and-permissions-modal +sidebar_label: Ck roles and permissions +--- + + + +The `ck-roles-and-permissions-modal` web component facilitates the management of roles and their associated permissions. It allows you to create, edit and manage roles assigning permissions using a **tree structure**, where each node represents a permission. + +* **Internal nodes**: represent categories or groups of permissions. They are parent nodes that can have child nodes (either other internal nodes or leaf nodes). When an internal node is selected, it implies that all its descendant nodes (both internal and leaf) are also selected. +* **Leaf nodes**: are the specific permissions themselves. These nodes represent actionable permissions (like "read", "edit", or "delete") and cannot have child nodes. +Selecting an internal node grants all the permissions contained within its child nodes, while selecting a leaf node grants only that specific permission. + + + +## Example +An example of the permissions tree structure: +```mermaid +graph TD + A[Users] + B[Patient] + C[Devices] + D[Delete] + E[Edit] + F[Read] + G[Delete] + + A --> B + B --> E + B --> F + A --> D + C --> G +``` + +The web component will follow this structure and allow you to check the permissions of the role you are creating. if you check an internal node it actually means that all the leaf nodes connected to that node have been checked. + +![ck-roles-and-permissions-modal](../img/ck-roles-and-permissions-modal.png) + +## Usage + +To integrate the `ck-roles-and-permissions-modal` into a Microfrontend Composer page, include the component in the page configuration. +Below is an example configuration: + +```json +{ + "type": "element", + "url": "/mia-care-web-components/mia-care-web-components.esm.js", + "tag": "ck-roles-and-permissions-modal", +} +``` + +Upon completing an action, a feedback message will be displayed, indicating success or failure. + +## Properties & Attributes + +| property | type | required | default | description | +|-------------------------|----------|----------|---------|-------------------------------------------------------------------------------------------------| +| `rolesManagementEndpoint` | `string` | false | /roles/ | Endpoint used to retrieve data of the roles. (See [Roles endpoint schema](#roles-endpoint-schema) for more information). | +| `permissionsManagementEndpoint` | `string` | false | /permissions/ | Endpoint used to retrieve data of the permissions. (See [Permissions endpoint schema](#permissions-endpoint-schema) for more information). | +| `width` | `string` or `number` | false | 70% | The width of the modal. It must a valid CSS value. | +| `readOnly` | `boolean` | false | false | When set to `true`, this value ensures the modal is in read-only mode, preventing user input. | + + +## Listens to + +| event | action | payload | +|--------------------------------------------------------------------------------|---------------------------------------------------|----------| +| [selected-data](../../../microfrontend-composer/back-kit/events#selected-data) | Triggers the opening of the modal in edit mod | The data of the role. Please note that the `_id` is required. | +| [add-new](../../../microfrontend-composer/back-kit/events#add-new) | Listens to the add-new event to open modal | - | + + +## Communication with Endpoints + +### Roles Management Endpoint + + + +It retrieves the list of roles and it allows either to create a new role or to edit an existing one +The endpoint should expose these methods + +* **GET by id**: Retrieve a specific role with all schema information. +* **POST**: Create a new role with permissions selected assigned. +* **PATCH by id**: It allows to patch a specific role by changing either name or the list of permissions. + +#### Schema + +| property | type | required | description | +|-------------------------|----------|---------|-------------------------------------------------------------------------------------------------| +| `_id` | `string` | false | The ID of the permission. This field is auto-generated from the backend. | +| `label` | `string` | false | Readable name of the role. | +| `value` | `string` | false | Identifier that defines the role. | +| `permissions` | `string[]` | false | [Values of the permissions](#permissions-endpoint-schema) of the role. + + +### Permission Endpoint + + + +This endpoint manages the entire permission tree. It must serve all available permissions, both internal nodes and leaf nodes. This allows the web component to build the permission tree structure correctly. + +It should expose an **EXPORT** which retrieve the list of all permissions + + +#### Schema + +| property | type | required | description | +|-------------------------|----------|---------|-------------------------------------------------------------------------------------------------| +| `_id` | `string` | false | The ID of the permission. This field is auto-generated from the backend. | +| `label` | `string` | false | Readable name of the permission. | +| `value` | `string` | false | The format of this value is created by associating the value of the parent nodes and the identifier of the node. For example parent1.parent2 or parent1.parent2.leaf4 | +| `description` | `string` | false | Description of the permission. | +| `type` | `Enum`: `leaf` or `intenalNode` | false | This value indicates whether the permission type is a leaf or an internal node. + + +following this [example](#example) the expected data might look like this: +```json +[ + { "label": "Devices", "value": "parent2", "type": "internalNode" }, + { "label": "Edit", "value": "parent1.parent2.leaf3", "type": "leaf" }, + { "label": "Delete", "value": "parent2.leaf2", "type": "leaf" }, + { "label": "Users", "value": "parent1", "type": "internalNode" }, + { "label": "Patient", "value": "parent1.parent2", "type": "internalNode" }, + { "label": "Read", "value": "parent1.parent2.leaf4" }, + { "label": "Delete", "value": "parent1.leaf1", "type": "leaf"} +] +``` + +This would correspond to the following tree: + +```mermaid +graph TD + A["label: Users
value: parent1
type: internalNode"] + B["label: Patient
value: parent1.parent2
type: internalNode"] + D["label: Delete
value: parent1.leaf1
type: leaf"] + E["label: Edit
value: parent1.parent2.leaf3
type: leaf"] + F["label: Read
value: parent1.parent2.leaf4
type: leaf"] + C["label: Devices
value: parent2
type: internalNode"] + G["label: Delete
value: parent2.leaf2
type: leaf"] + + A --> B + B --> E + B --> F + A --> D + C --> G +``` + +### Notes + +Remember, the permissions for a role will always consist of the leaf node values, but the permissionsManagementEndpoint must provide the entire tree structure, including internal nodes, for the modal to work properly. + +When adding a new permission, such as "Read" under a new category "Documents" the permissionsManagementEndpoint must return: + +- An internal node for the "Documents" category with the value "documents". +- A leaf node for the "Read" permission with the value "documents.write". + +This ensures that the frontend can properly display the hierarchy of permissions. + +The expected response format in this case would be: +```json +[ + { "label": "Documents", "value": "documents", "type": "internalNode" }, + { "label": "Write", "value": "documents.write", "type": "leaf" } +] +``` diff --git a/docs/runtime_suite/care-kit/changelog.md b/docs/runtime_suite/care-kit/changelog.md index 1fc6ae6247..13def1f559 100644 --- a/docs/runtime_suite/care-kit/changelog.md +++ b/docs/runtime_suite/care-kit/changelog.md @@ -15,6 +15,17 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [v2.9.1] + +- Upgrade Node.js to v20 and remove unused dependencies +- Fix regression in `ck-threshold-modal` component caused by `values` field in prototypes, which are now ignored + +## [v2.9.0] + +- Added `roles-and-permissions-modal` web component +- Fix medical records loading data +- Fix `add-plan-modal` handling of adherence and compliance on edit + ## [v2.8.5] - Fix calendar event box width @@ -39,8 +50,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [v2.8.2] -- Update add-plan-modal to edit devices -- Update add-plan-modal to include devices on create +- Update `add-plan-modal` to edit devices +- Update `add-plan-modal` to include devices on create ## [v2.8.1] diff --git a/docs/runtime_suite/care-kit/img/ck-roles-and-permissions-modal.png b/docs/runtime_suite/care-kit/img/ck-roles-and-permissions-modal.png new file mode 100644 index 0000000000..d91d68b917 Binary files /dev/null and b/docs/runtime_suite/care-kit/img/ck-roles-and-permissions-modal.png differ diff --git a/docs/runtime_suite/fhir-adapter/10_overview_and_usage.md b/docs/runtime_suite/fhir-adapter/10_overview_and_usage.md index 09103efc36..55821e3dd2 100644 --- a/docs/runtime_suite/fhir-adapter/10_overview_and_usage.md +++ b/docs/runtime_suite/fhir-adapter/10_overview_and_usage.md @@ -113,7 +113,7 @@ curl --request POST \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'client-key: client-key' \ - --data '{"firstName":"Mario","lastName":"Rossi","birthDate":"12-03-1987"}' + --data '{"firstName":"John","lastName":"Doe","birthDate":"12-03-1987"}' ``` in response, you will get a JSON object like this: diff --git a/docs/runtime_suite/fhir-adapter/changelog.md b/docs/runtime_suite/fhir-adapter/changelog.md index 5adc1e1bdd..dbc1696242 100644 --- a/docs/runtime_suite/fhir-adapter/changelog.md +++ b/docs/runtime_suite/fhir-adapter/changelog.md @@ -15,24 +15,39 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). -## [1.0.2] 2024-06-25 +## [1.0.4] 2024-11-12 + +## Changed + +- Update Node.js to v20 (LTS) and dependencies + +## [1.0.3] 2024-06-25 ## Changed - Node version updated to lts/hydrogen -- Untracked: Fix endpoint tags for API Portal documentation +- Fix endpoint tags for API Portal documentation + +## [1.0.2] 2023-05-16 + +## Changed + +- Update dependencies ## [1.0.1] 2023-02-01 ### Fixed + - Minor vulnerability fix. ## [1.0.0] 2022-09-28 ### Added + - Update `json-schema-converter` version to `2.2.0`. ### Removed + - Removed custom error management in file upload and download. ## [0.1.1] 2022-07-07 diff --git a/docs/runtime_suite/form-service-frontend/changelog.md b/docs/runtime_suite/form-service-frontend/changelog.md index 441cbeacd3..70c7949fd0 100644 --- a/docs/runtime_suite/form-service-frontend/changelog.md +++ b/docs/runtime_suite/form-service-frontend/changelog.md @@ -15,6 +15,11 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). +## 2.1.0 2024-11-06 + +- Upgrade dependencies and CI/CD pipeline +- Added custom title to the expired Modal + ## 2.0.5 2024-05-23 - fixed bug on expired form behavior diff --git a/docs/runtime_suite/messaging-service/changelog.md b/docs/runtime_suite/messaging-service/changelog.md index b1b9c5e844..46953ef3a0 100644 --- a/docs/runtime_suite/messaging-service/changelog.md +++ b/docs/runtime_suite/messaging-service/changelog.md @@ -15,6 +15,12 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [1.7.1] 2024-10-25 + +### Fixed + +- Replace newline escape sequences (`\n`, `\n\r`, `\r` and `\r\n`) with `
` tag in HTML email messages + ## [1.7.0] 2024-05-23 - Update Node.js to v20 (LTS) diff --git a/docs/runtime_suite/notification-manager-service/10_overview.md b/docs/runtime_suite/notification-manager-service/10_overview.md index d0fd981365..3f08f5ace4 100644 --- a/docs/runtime_suite/notification-manager-service/10_overview.md +++ b/docs/runtime_suite/notification-manager-service/10_overview.md @@ -119,6 +119,15 @@ If you need to customize the requests sent to the external services, you should ::: +## Providers + +| Provider | Email | SMS | Push Notifications | Voice calls | WhatsApp messages | +|------------|-------|-----|--------------------|-------------|-------------------| +| Amazon SES | ✓ | | | | | +| Firebase | | | ✓ | | | +| Kaleyra | | ✓ | | ✓ | ✓ | +| Twilio | | ✓ | | | | + ## Channels Each channel has external dependencies, including other Mia-Platform plugins, service providers accounts and specific fields on the message templates and users CRUD collections. diff --git a/docs/runtime_suite/notification-manager-service/20_configuration.md b/docs/runtime_suite/notification-manager-service/20_configuration.md index 35c1603b76..0d0737d5a7 100644 --- a/docs/runtime_suite/notification-manager-service/20_configuration.md +++ b/docs/runtime_suite/notification-manager-service/20_configuration.md @@ -345,6 +345,85 @@ The properties used by the service are the following. | emitters | `Array of string` | No | List of emitters that should trigger the sending of notifications. | | reminders | `Array of string` | No | List of reminders to set, expressed as [ISO 8601 duration][iso-8601-duration] strings (for example, `P1D` for one day and `PT1H` for an hour before). | +## Views + +### Notification messages view + +:::info + +This view is required by the following endpoints and must be enabled explicitly by setting the [`NOTIFICATIONS_MESSAGES_VIEW_NAME` environment variable][environment-variables]: + +- [GET /notification-messages/count][get-notification-messages-count] +- [GET /notification-messages/][get-notification-messages] + +By default, the view is not enabled and these endpoints are not available. + +::: + +This [MongoDB view][mongodb-view] runs an aggregation pipeline on the [notifications CRUD collection][crud-notifications] to return a distinct document for each message sent, i.e. each element in the notification `messages` array field. + +The MongoDB view must have the properties listed in the following table. + +| Name | Type | Required | Description | +|----------------|----------|----------|------------------------------------------------------------------------| +| notificationId | `String` | No | CRUD _id of the notification. | +| recipient | `String` | No | ID of the user the message was sent to. | +| event | `String` | No | The name of the event. | +| date | `Date` | No | When the message was sent. | +| status | `String` | No | If the message was processed correctly (`SUCCESS`) or not (`FAILURE`). | +| channel | `String` | No | Name of the channel the message was sent on. | +| templateName | `String` | No | Name of the template used to send the message on the channel. | +| message | `Object` | No | The details about the message sent (title, subtitle, body, etc.) | + +This is the aggregation pipeline, that you can customize for example by adding additional fields. + +```json +[ + { + "$match": { + "__STATE__": "PUBLIC" + } + }, + { + "$unwind": { + "path": "$messages" + } + }, + { + "$project": { + "_id": { + "$concat": [ + { + "$toString": "$_id" + }, + "-", + "$messages.channel", + "-", + "$messages.templateName" + ] + }, + "creatorId": "$creatorId", + "createdAt": "$createdAt", + "updaterId": "$updaterId", + "updatedAt": "$updatedAt", + "__STATE__": "$__STATE__", + "notificationId": { + "$toString": "$_id" + }, + "recipient": "$recipient", + "event": "$event.name", + "date": "$createdAt", + "status": "$messages.status", + "channel": "$messages.channel", + "templateName": "$messages.templateName", + "message": "$messages.service.message" + } + } +] +``` + +The `_id` field is computed dinamically based on the notification `_id` and is unique across all messages. + ## Environment variables :::info @@ -385,6 +464,7 @@ If `USERS_API_ENDPOINT` is not set, the users data is retrieved as in previous v | **EVENTS_SETTINGS_CRUD_NAME** | Yes | - | * | Name of the CRUD collection containing event settings. | | **NOTIFICATIONS_CRUD_NAME** | Yes | - | * | Name of the CRUD collection containing statistics about notifications sent. | | **NOTIFICATIONS_SETTINGS_CRUD_NAME** | Yes | - | * | Name of the CRUD collection containing the notifications settings. | +| **NOTIFICATIONS_MESSAGES_VIEW_NAME** | No | - | >= 2.4.0 | Name of the MongoDB view containing the notification messages. | | **MAIL_SERVICE_URL** | Email notifications | - | * | URL of the SES Mail Notification Service. Required if you want to send e-mails. | | **SMS_SERVICE_URL** | SMS notifications | - | * | URL of the SMS Service. Required if you want to send SMS. | | **FILE_SERVICE_URL** | Email attachments | - | * | URL of the File Service. Required if you want to send emails with attachments. | @@ -392,11 +472,11 @@ If `USERS_API_ENDPOINT` is not set, the users data is retrieved as in previous v | **KAFKA_CLIENT_ID** | Push notifications | - | * | Required if you want to send push notifications. | | **KAFKA_BROKERS** | Push notifications | - | * | List of comma separated brokers address. Required if you want to send push notifications. | | **KAFKA_TOPICS** | Push notifications | - | * | List of comma separated topics. Required if you want to send push notifications. | -| **KAFKA_AUTH_MECHANISM** | Push notifications | - | * | Authentication mechanism, used only if `KAFKA_USERNAME` and `KAFKA_PASSWORD` have a value. Defaults to `PLAIN`. | +| **KAFKA_AUTH_MECHANISM** | Push notifications | PLAIN | * | Authentication mechanism, used only if `KAFKA_USERNAME` and `KAFKA_PASSWORD` have a value. | | **KAFKA_USERNAME** | Push notifications | - | * | | | **KAFKA_PASSWORD** | Push notifications | - | * | | -| **KAFKA_CONNECTION_TIMEOUT** | Push notifications | - | * | Time in milliseconds to wait for a successful connection. Defaults to 1000. | -| **KAFKA_AUTHENTICATION_TIMEOUT** | Push notifications | - | * | Time in milliseconds to wait for a successful authentication. Defaults to 1000. | +| **KAFKA_CONNECTION_TIMEOUT** | Push notifications | 1000 | * | Time in milliseconds to wait for a successful connection. | +| **KAFKA_AUTHENTICATION_TIMEOUT** | Push notifications | 1000 | * | Time in milliseconds to wait for a successful authentication. | | **KAFKA_EVENTS_TOPIC_NAME** | No | - | * | Name of the Kafka topic for incoming events. If not set, automatic notifications via Kafka are disabled. | | **KAFKA_ERRORS_TOPIC_NAME** | No | - | * | Name of the Kafka topic for unknown events. If not set, automatic notifications via Kafka are disabled. | | **KAFKA_CONSUMER_GROUP** | No | - | * | Name of the Kafka consumer group for Kafka topic for incoming events. | @@ -406,7 +486,7 @@ If `USERS_API_ENDPOINT` is not set, the users data is retrieved as in previous v | **CUSTOM_HANDLERS_FOLDER** | Custom handlers | - | * | The path to the directory containing the definitions (i.e. the configmaps) of the custom handlers. | | **GOOGLE_APPLICATION_CREDENTIALS** | Push notifications | - | >= 2.2.0 | The application credentials given by Firebase. Must be loaded from a [secret][service-secrets]. | | **DEFAULT_LOCALE** | No | - | >= 2.3.0 | A [BCP 47 language tag][bcp-47-language-tag] used as default locale by [`toLocale` custom helper][message-interpolation] in message templates. | -| **USERS_API_ENDPOINT** | No | - | >= 2.3.0 | The url of the API queried to fetch users data. | +| **USERS_API_ENDPOINT** | No | - | >= 2.3.0 | The url of the API queried to fetch users data. | ## Channels configuration @@ -817,6 +897,7 @@ The following default reminder event handlers both filter the notification setti [rond]: https://rond-authz.io/ [twilio-invalid-number]: https://www.twilio.com/docs/api/errors/21212 +[mongodb-view]: /development_suite/api-console/api-design/mongo_views.md [appointment-manager]: /runtime_suite/appointment-manager/10_overview.md [files-service]: /runtime_suite/files-service/configuration.mdx [localized-strings]: /microfrontend-composer/back-kit/40_core_concepts.md @@ -829,6 +910,7 @@ The following default reminder event handlers both filter the notification setti [crud-events]: #events-crud [crud-events-settings]: #event-settings-crud [crud-notification-settings]: #notification-settings-crud +[crud-notifications]: #notifications-crud [crud-users]: #users-crud [environment-variables]: #environment-variables [service-configuration]: #service-configuration @@ -840,3 +922,5 @@ The following default reminder event handlers both filter the notification setti [patch-event-settings]: ./30_usage.md#patch-event-settingsid [post-event-settings]: ./30_usage.md#post-event-settings [delete-event-settings]: ./30_usage.md#delete-event-settingsid +[get-notification-messages-count]: ./30_usage.md#get-notification-messagescount +[get-notification-messages]: ./30_usage.md#get-notification-messages diff --git a/docs/runtime_suite/notification-manager-service/30_usage.md b/docs/runtime_suite/notification-manager-service/30_usage.md index 6937e22c9e..0748ea04a5 100644 --- a/docs/runtime_suite/notification-manager-service/30_usage.md +++ b/docs/runtime_suite/notification-manager-service/30_usage.md @@ -618,121 +618,79 @@ Please check the CHANGELOG before upgrading. :::info +**v2.4.0**. This endpoint requires the [Notification Messages MongoDB view][notification-messages-mongodb-view]. + +::: + +:::info + **v2.3.0**. This endpoint is available only since v2.3.0. ::: -This endpoint is a proxy to the `GET /notifications` endpoint of the [templates CRUD][crud-templates], and it returns the messages of the queried notifications. See [notifications CRUD][crud-notification] and [messages CRUD][crud-notification-messages]. +This endpoint is a proxy to the `GET /` of [Notification Messages MongoDB view][notification-messages-mongodb-view] and returns the messages matching the given query. -If the queried notifications look like these: +Given a notification like this: ```json -[ - { - "_id": "663ccd65dee93b2a6a6885d1", - "event": { - "_id": "663ccd63dee93b2a6a6885d0", - "name": "Update appointment", - "payload": { - "recipient": "663ccce5dee93b2a6a6885ty", - "templateName": "update-appointment" - }, - "source": { - "channel": "http", - "requestId": "6e4ddc4eda4ce1f422b285a80da3128a" - }, - "status": "RECEIVED" +{ + "_id": "663ccd65dee93b2a6a6885d1", + "event": "Update appointment"{ + "_id": "663ccd63dee93b2a6a6885d0", + "name": , + "payload": { + "recipient": "663ccce5dee93b2a6a6885ty", + "templateName": "update-appointment" }, - "recipient": "663ccce5dee93b2a6a6885ty", - "messages": [ - { - "channel": "email", - "templateName": "new-appointment", - "status": "SUCCESS" - }, - { - "channel": "sms", - "templateName": "new-appointment", - "status": "FAILED" - } - ] + "source": { + "channel": "http", + "requestId": "6e4ddc4eda4ce1f422b285a80da3128a" + }, + "status": "RECEIVED" }, - { - "_id": "812rcd65dee93b2a6a9845z98", - "event": { - "_id": "758acd63dee93b2a6a68125a", - "name": "New appointment", - "payload": { - "recipient": "recipient-2", - "templateName": "new-appointment" - }, - "source": { - "channel": "http", - "requestId": "6e4ddc4eda4ce1f422b285a80da3128a" - }, - "status": "RECEIVED" + "recipient": "663ccce5dee93b2a6a6885ty", + "messages": [ + { + "channel": "email", + "templateName": "new-appointment", + "status": "SUCCESS" }, - "recipient": "675cdse5dee93b2a6a64565rf", - "messages": [ - { - "channel": "email", - "templateName": "new-appointment", - "status": "SUCCESS" - } - ] - } -] - + { + "channel": "sms", + "templateName": "new-appointment", + "status": "FAILED" + } + ] +} ``` -the response with the messages looks like the following: +the following messages would be returned: ```json [ { - "_id": "663ccd65dee93b2a6a6885d1-m1", - "event": { - "_id": "663ccd63dee93b2a6a6885d0", - "name": "Update appointment", - "payload": {}, - "source": {} - }, + "_id": "663ccd65dee93b2a6a6885d1-fea80f2db003d4ebc4536023814aa885", + "event": "Update appointment", "recipient": "663ccce5dee93b2a6a6885ty", - "message": { - "channel": "email", - "templateName": "new-appointment", - "status": "SUCCESS" - } + "channel": "email", + "templateName": "new-appointment", + "status": "SUCCESS" }, { - "_id": "663ccd65dee93b2a6a6885d1-m2", - "event": { - "_id": "663ccd63dee93b2a6a6885d0", - "name": "Update appointment", - "payload": {}, - "source": {} - }, + "_id": "663ccd65dee93b2a6a6885d1-0956d2fbd5d5c29844a4d21ed2f76e0c", + "event": "Update appointment", "recipient": "663ccce5dee93b2a6a6885ty", - "message": { - "channel": "sms", - "templateName": "new-appointment", - "status": "FAILED" - } + "channel": "sms", + "templateName": "new-appointment", + "status": "FAILED" }, { - "_id": "812rcd65dee93b2a6a9845z98-m1", - "event": { - "_id": "758acd63dee93b2a6a68125a", - "name": "New appointment", - "payload": {}, - "source": {} - }, + "_id": "812rcd65dee93b2a6a9845z98-3a685826dee20d9afd3bc637b0615adb", + "event": "New appointment", "recipient": "675cdse5dee93b2a6a64565rf", - "message": { - "channel": "email", - "templateName": "new-appointment", - "status": "SUCCESS" - } + "channel": "email", + "templateName": "new-appointment", + "status": "SUCCESS" } ] ``` @@ -748,12 +706,17 @@ Please check the CHANGELOG before upgrading. :::info -**v2.3.0**. This endpoint is available only since v2.3.0. +**v2.4.0**. This endpoint requires the [Notification Messages MongoDB view][notification-messages-mongodb-view]. ::: -This endpoint is a proxy to the `GET /notifications` endpoint of the [templates CRUD][crud-templates], and it returns the number of messages of the queried notifications. See [notifications CRUD][crud-notification] and [messages CRUD][crud-notification-messages]. +:::info + +**v2.3.0**. This endpoint is available only since v2.3.0. + +::: +This endpoint is a proxy to the `GET /count` endpoint of the [Notification Messages MongoDB view][notification-messages-mongodb-view] and returns the number of messages matching the given query. ## Custom handler API @@ -2039,6 +2002,7 @@ When the handler receives such an event it performs the following operations: [crud-users]: ./20_configuration.md#users-crud [crud-templates]: ./20_configuration.md#templates-crud [service-configuration]: ./20_configuration.md#service-configuration +[notification-messages-mongodb-view]: 20_configuration.md#notification-messages-view [build-messages]: #buildmessages [build-reminders]: #buildreminders diff --git a/docs/runtime_suite/notification-manager-service/changelog.md b/docs/runtime_suite/notification-manager-service/changelog.md index 91ad49d2e8..7f522af3c9 100644 --- a/docs/runtime_suite/notification-manager-service/changelog.md +++ b/docs/runtime_suite/notification-manager-service/changelog.md @@ -15,6 +15,23 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [2.4.0] 2024-10-29 + +### Added + +- Add notification messages MongoDB view +- Add `NOTIFICATIONS_MESSAGES_VIEW_NAME` environment variable to configure the notification messages MongoDB view + +### Changed + +- `GET /notification-messages/count` is a proxy to the `GET /count` endpoint of the notification messages MongoDB view +- `GET /notification-messages/` is a proxy to the `GET /` endpoint of the notification messages MongoDB view + +### Fixed + +- Sanitize logs that could leak sensitive or personal information +- Replace newline escape sequences (`\n`, `\n\r`, `\r` and `\r\n`) with `
` tag in HTML email messages + ## [2.3.0] 2024-06-11 ### Fixed diff --git a/docs/runtime_suite/sms-service/10_overview.md b/docs/runtime_suite/sms-service/10_overview.md index 58ba0ef7d3..a20302f807 100644 --- a/docs/runtime_suite/sms-service/10_overview.md +++ b/docs/runtime_suite/sms-service/10_overview.md @@ -52,7 +52,8 @@ This section provides a security checklist to configure providers in order for a #### Twilio - [ ] Disable automatic recharge of the account balance under the *Billing Overview* section of the Twilio project console -- [ ] Configure SMS Geo-Permissions in the Twilio project console, on the [Messaging Geographic Permissions][twilio-geo-permissions] page. +- [ ] Configure SMS Geo-Permissions in the Twilio project console, on the [Messaging Geographic Permissions][twilio-geo-permissions] page. +- [ ] Enable [SMS Pumping Protection for Programmable Messaging][twilio-sms-pumping-protection-programmable-messaging] (this is a paid feature, check official [Twilio pricing page][twilio-pricing] for more details) #### Kaleyra @@ -71,5 +72,7 @@ This section provides a security checklist to configure providers in order for a [twilio-sms-fraud]: https://support.twilio.com/hc/en-us/articles/8360406023067-SMS-Traffic-Pumping-Fraud "Twilio sms pumping fraud" [twilio-balance-api]: https://support.twilio.com/hc/en-us/articles/360025294494-Check-Your-Twilio-Account-Balance "Twilio balance api" [twilio-geo-permissions]: https://console.twilio.com/us1/develop/sms/settings/geo-permissions?frameUrl=%2Fconsole%2Fsms%2Fsettings%2Fgeo-permissions%3Fx-target-region%3Dus1 "Twilio Geo Permissions" +[twilio-pricing]: https://www.twilio.com/en-us/sms/pricing/ +[twilio-sms-pumping-protection-programmable-messaging]: https://www.twilio.com/docs/messaging/features/sms-pumping-protection-programmable-messaging [environment-variables]: ./20_configuration.md#Environment-variables "Environment variables | Configuration" diff --git a/docs/runtime_suite/teleconsultation-service-backend/changelog.md b/docs/runtime_suite/teleconsultation-service-backend/changelog.md index 4ba4d2b286..f7859f3e0b 100644 --- a/docs/runtime_suite/teleconsultation-service-backend/changelog.md +++ b/docs/runtime_suite/teleconsultation-service-backend/changelog.md @@ -15,6 +15,10 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [2.0.1] 2024-10-29 + +- Removed unused configuration variables `environment` and `mode` + ## [2.0.0] 2024-10-10 ### BREAKING CHANGES diff --git a/docs/runtime_suite/teleconsultation-service-frontend/changelog.md b/docs/runtime_suite/teleconsultation-service-frontend/changelog.md index 4297189cf9..cdc49fae6f 100644 --- a/docs/runtime_suite/teleconsultation-service-frontend/changelog.md +++ b/docs/runtime_suite/teleconsultation-service-frontend/changelog.md @@ -15,6 +15,15 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). +## 2.0.1 2024-10-29 + +- Fixed restart call button copy and style +- Fixed CSP configuration + +## 2.0.0 2024-10-15 + +- Upgrade dependencies and CI/CD pipeline + ## 1.5.1 2024-03-13 - Added spanish locale diff --git a/docs/runtime_suite/therapy-and-monitoring-manager/10_overview.md b/docs/runtime_suite/therapy-and-monitoring-manager/10_overview.md index adf9e20e49..6c6cf741d0 100644 --- a/docs/runtime_suite/therapy-and-monitoring-manager/10_overview.md +++ b/docs/runtime_suite/therapy-and-monitoring-manager/10_overview.md @@ -177,6 +177,7 @@ For each prototype you need to define: - the name; - the schema; - the labels for the schema fields (**required** only if you use the TMM with the companion FE component); +- the values for the schema fields (**required** only if you use the TMM with the companion FE component); - the hints for the schema fields (only for therapy directives, should provide a list of admitted or suggested values for a schema field). TMM supports localization for `name`, `labels` and `hints`, using a syntax like the following (`en` is ISO 639-1 language code for English, `it` for Italian): @@ -197,6 +198,14 @@ TMM supports localization for `name`, `labels` and `hints`, using a syntax like "it": "Dieta" } }, + "values": { + "bodyTemperature": { + "path": "observations[0].value" + }, + "diet": { + "path": "observations[1].value" + } + }, "hints": { "diet": [ { @@ -414,6 +423,41 @@ The integrated validation system currently supports the following threshold vali } ``` +:::warning + +The value of the `propertyName` should be the path to the value of the specific attributes in the prototype schema. If your schema is not a plan object you can use the `values` on the prototype to specify the path. +Here you can find the examples: + +- If you have a plane object the `propertyName` will be simply equal to that record like `systolicBloodPresure` or `diastolicBloodPresure`. +```json +{ + "systolicBloodPresure": 120, + "diastolicBloodPresure": 66 +} +``` + +- If you have a a complicated schema the `propertyName` should be equal to that path of the value like `observations[0].value` for `systolicBloodPresure` and `observations[1].value` for the value of `diastolicBloodPresure`. +```json +{ + "period": { + "startDate": "2024-01-01" + }, + "observations": [ + { + "code": "systolicBloodPresure", + "unit": "mmHg", + "value": 120 + }, + { + "code": "diastolicBloodPresure", + "unit": "mmHg", + "value": 66 + } + ] +} +``` +::: + :::danger The integrated validation system is designed under the assumption that the property of the detection value referred by a threshold contains one or two numeric values. If the value is not a number or an array of two numbers, depending on the operator, an error is returned. diff --git a/docs/runtime_suite/therapy-and-monitoring-manager/20_configuration.md b/docs/runtime_suite/therapy-and-monitoring-manager/20_configuration.md index 483eca608e..47a3226e13 100644 --- a/docs/runtime_suite/therapy-and-monitoring-manager/20_configuration.md +++ b/docs/runtime_suite/therapy-and-monitoring-manager/20_configuration.md @@ -88,7 +88,15 @@ A prototype example can be used to validate detections related to blood pressure "en": "Maximum pressure", "it": "Pressione massima" } - } + }, + "values": { + "minimumBloodPressure": { + "path": "observations[0].value" + }, + "maximumBloodPressure": { + "path": "observations[1].value" + } + }, } ``` @@ -174,6 +182,8 @@ Note that, modifying an identifier in an already running system can lead to inco * **Labels**: the labels for the schema fields, each one can be a string or translation object. +* **values**: the values for the schema fields, each one must be an object containing the path of the field in the detection value containing the corresponding value to compare against the thresholds. + * **Hints**: the hints for the schema fields, each one can be a string or translation object. This is only supported by therapy directives, to provide a list of admitted or suggested values for the field. ## CRUD collections @@ -319,16 +329,18 @@ If you use the integrated validation service, field names in the `value` object ::: -| Name | Type | Required (Yes/No) | Nullable (Yes/No) | -|-------------|-----------|-------------------|-------------------| -| planType | `string` | Yes | No | -| planId | `string` | Yes | No | -| value | `Object` | No | No | -| observedAt | `Date` | Yes | No | -| doctorId | `string` | No | No | -| patientId | `string` | Yes | No | -| isCompliant | `boolean` | No | No | -| deviceId | `string` | No | No | +| Name | Type | Required (Yes/No) | Nullable (Yes/No) | +|--------------------|-------------------|-------------------|-------------------| +| planType | `String` | Yes | No | +| planId | `String` | Yes | No | +| value | `Object` | No | No | +| observedAt | `Date` | Yes | No | +| doctorId | `String` | No | No | +| patientId | `String` | Yes | No | +| isCompliant | `Boolean` | No | No | +| deviceId | `String` | No | No | +| thresholds | `Array of object` | No | No | +| thresholdsExceeded | `Boolean` | No | No | ## Thresholds validation diff --git a/docs/runtime_suite/therapy-and-monitoring-manager/30_usage.md b/docs/runtime_suite/therapy-and-monitoring-manager/30_usage.md index 6779e780e2..7a968ef70b 100644 --- a/docs/runtime_suite/therapy-and-monitoring-manager/30_usage.md +++ b/docs/runtime_suite/therapy-and-monitoring-manager/30_usage.md @@ -361,18 +361,21 @@ These endpoints return 404 if no therapy or monitoring with given id is found. Detections represent tasks performed by the patient and are related to therapies or monitorings. The data model is the following: -| Name | Required (Yes/No) | Description | -|-------------|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| planType | Yes | Type of plan - `therapy` or `monitoring` - the detection refers to. | -| planId | Yes | Identifier of the therapy or monitoring plan the detection refers to. | -| value | Only for monitoring | The detection value is an arbitrary object and must match the validation schema defined by the associated prototype. Note that the association between the prototype and the detection is not available in the detection data model, but it is defined at the therapy or monitoring level. | -| planId | Yes | Identifier of the therapy or monitoring plan the detection refers to. | -| observedAt | Yes | Date/time at which the detection has been performed. | -| isCompliant | No | It indicates if the detection is compliant to what the physician has descripted in the plan. This value is submitted by the patient. | -| doctorId | No | Identifier of the doctor that creates the detection. Note that the doctor that creates the detection can be different from the physician that created the monitoring or therapy plan. | -| patientId | Yes | Identifier of the patient that creates the detection. | +| Name | Required (Yes/No) | Description | +|--------------------|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| planType | Yes | Type of plan - `therapy` or `monitoring` - the detection refers to. | +| planId | Yes | Identifier of the therapy or monitoring plan the detection refers to. | +| value | Only for monitoring | The detection value is an arbitrary object and must match the validation schema defined by the associated prototype. Note that the association between the prototype and the detection is not available in the detection data model, but it is defined at the therapy or monitoring level. | +| planId | Yes | Identifier of the therapy or monitoring plan the detection refers to. | +| observedAt | Yes | Date/time at which the detection has been performed. | +| isCompliant | No | It indicates if the detection is compliant to what the physician has descripted in the plan. This value is submitted by the patient. | +| doctorId | No | Identifier of the doctor that creates the detection. Note that the doctor that creates the detection can be different from the physician that created the monitoring or therapy plan. | +| patientId | Yes | Identifier of the patient that creates the detection. | +| thresholds | No | The list of thresholds the detection was validated against. | +| thresholdsExceeded | No | If the detection exceeds one or more thresholds. | If the **NOTIFICATION_MANAGER_URL** environment variable is correctly set, the handler will send a request to the `POST /notification-events/` endpoint of the Notification Manager, including the following information in the request body: + - **key** (string): the identifier of the deleted therapy or monitoring. - **name** (string): the event name, which is `TMM/TherapyDeleted/v1` for therapies and `TMM/MonitoringDeleted/v1` for monitorings. - **payload**(*object*): the deleted therap or monitoring. @@ -512,7 +515,7 @@ These endpoints return 200 and the number of detections matching the query. Insert a new detection in the CRUD and performs the following operations: -- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds; +- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds and store the results in the CRUD `thresholds` and `thresholdsExceeded` fields; - if the [`NOTIFICATION_MANAGER_URL` environment variable][environment-variables] is set, send a notification to the physician through the Notification Manager service. This endpoint is a proxy to the CRUD `POST /` endpoint. @@ -568,7 +571,7 @@ This endpoint returns 400 and a body with the structure shown below if the detec Insert multiple detection in the CRUD and, for each detection, performs the following operations: -- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds; +- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds and store the results in the CRUD `thresholds` and `thresholdsExceeded` fields; - if the [`NOTIFICATION_MANAGER_URL` environment variable][environment-variables] is set, send a notification to the physician through the Notification Manager service. This endpoint is a proxy to the CRUD `POST /bulk` endpoint. @@ -637,7 +640,7 @@ In such scenario the endpoint returns 400 and a body with the structure shown be Update an existing detection identified by the `:id` path parameter and performs the following operations: -- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds; +- if the [`VALIDATION_SERVICE` environment variable][environment-variables] is set, check if the detection exceeds any of the monitoring thresholds and update the results in the CRUD `thresholds` and `thresholdsExceeded` fields; - if the [`NOTIFICATION_MANAGER_URL` environment variable][environment-variables] is set, send a notification to the physician through the Notification Manager service. This endpoint is a proxy to the CRUD `PATCH /:id` endpoint. @@ -847,7 +850,15 @@ This endpoint returns 200 and a list of the prototypes matching the query. "en": "maximum pressure", "it": "pressione massima" } - } + }, + "values": { + "minimumBloodPressure": { + "path": "observations[0].value" + }, + "maximumBloodPressure": { + "path": "observations[1].value" + } + }, }] ``` diff --git a/docs/runtime_suite/therapy-and-monitoring-manager/40_migration.md b/docs/runtime_suite/therapy-and-monitoring-manager/40_migration.md new file mode 100644 index 0000000000..daf97bd726 --- /dev/null +++ b/docs/runtime_suite/therapy-and-monitoring-manager/40_migration.md @@ -0,0 +1,44 @@ +--- +id: migration +title: Migration +sidebar_label: Migration +--- + + + +This document provides information to migrate from a previous version of the service. + +## 0.5.0 + +### CRUD collections + +Add the following fields to the [detections CRUD collection][crud-detections]: + +| Name | Type | Required (Yes/No) | Nullable (Yes/No) | +|--------------------|-------------------|-------------------|-------------------| +| thresholds | `Array of object` | No | No | +| thresholdsExceeded | `Boolean` | No | No | + +## 0.4.0 + +### CRUD collections + +- Add the following fields to the [detections CRUD collection][crud-detections]: + +| Name | Type | Required (Yes/No) | Nullable (Yes/No) | +|----------|----------|-------------------|-------------------| +| deviceId | `String` | No | No | + +- Add the following fields to the [monitorings CRUD collection][crud-monitorings]: + +| Name | Type | Required (Yes/No) | Nullable (Yes/No) | +|-----------------|-------------------|-------------------|-------------------| +| assignedDevices | `Array of string` | No | No | + + +[crud-detections]: ./20_configuration.md#detections +[crud-monitorings]: 20_configuration.md#monitorings diff --git a/docs/runtime_suite/therapy-and-monitoring-manager/changelog.md b/docs/runtime_suite/therapy-and-monitoring-manager/changelog.md index 7a1613537f..16c3a6ee37 100644 --- a/docs/runtime_suite/therapy-and-monitoring-manager/changelog.md +++ b/docs/runtime_suite/therapy-and-monitoring-manager/changelog.md @@ -15,6 +15,18 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [0.5.0] 2024-10-30 + +### Changed + +- Save thresholds validation results when detection is created or updated +- Add `values` to the prototypes schema. +- Upgrade `custom-plugin-lib` to version `7.0.0` and `fastify-cron` to `1.3.1` and add default error handler. + +### Fixed + +- Fix bug causing detections reported as OK if a threshold field is not found in the detection value. + ## [0.4.0] 2024-09-11 - Update Node.js to v20 (LTS) diff --git a/docs/runtime_suite_templates/node.js-mia-care-samd-template/10_overview.md b/docs/runtime_suite_templates/node.js-mia-care-samd-template/10_overview.md index d345319701..9456953863 100644 --- a/docs/runtime_suite_templates/node.js-mia-care-samd-template/10_overview.md +++ b/docs/runtime_suite_templates/node.js-mia-care-samd-template/10_overview.md @@ -10,9 +10,9 @@ DO NOT MODIFY IT BY HAND. Instead, modify the source file and run the aggregator to regenerate this file. --> -`Node.js Mia-Care Template` is the best template to start creating a service in NodeJs, integrated inside your platform. This template contains tools to simplifying the building Software as a Medical Device (SaMD). +`Node.js Mia-Care Template` is the best template to start creating a service in Node.js integrated inside your platform. This template contains tools to simplify building Software as a Medical Device (SaMD). -This template leverages Mia Platform [custom-plugin-lib][custom-plugin-lib]. +This template leverages Mia Platform [custom-plugin-lib][custom-plugin-lib]. `custom-plugin-lib` is a [node.js][node.js] library developed by Mia-Platform. This library contains configurations and functions that will help you to modify your template with easiness. If you want to learn how to modify this template and create your node microservice with custom logic, follow this [walkthrough][walkthrough]. diff --git a/docs/runtime_suite_templates/node.js-mia-care-samd-template/20_walkthrough.md b/docs/runtime_suite_templates/node.js-mia-care-samd-template/20_walkthrough.md index d4d93a7401..50b99fe21b 100644 --- a/docs/runtime_suite_templates/node.js-mia-care-samd-template/20_walkthrough.md +++ b/docs/runtime_suite_templates/node.js-mia-care-samd-template/20_walkthrough.md @@ -60,6 +60,9 @@ const customService = require('@mia-platform/custom-plugin-lib')(envVarsSchema) const getHelloWorld = require('./src/endpoints/hello-world/get') +const { logMethod } = require('./src/lib/utils') +const { AUDIT_TRAIL_LOG_LEVEL } = require('./src/lib/constants') + module.exports = customService(async function index(service) { service.register(getHelloWorld) @@ -73,16 +76,29 @@ module.exports = customService(async function index(service) { decorateRequestWithBuildErrorResponse(service) }) + +module.exports.options = { + logger: { + customLevels: { + audit: AUDIT_TRAIL_LOG_LEVEL, + }, + hooks: { + logMethod, + }, + }, +} ``` The `index.js` file already contains: -- the definition of an simple endpoint `GET /hello-world`; +- the definition of a simple endpoint `GET /hello-world`; - the definition of the Reply Fastify decorators for the error management; -- the definition of the Request Fastify decorators to enrich the request object. +- the definition of the Request Fastify decorators to enrich the request object; +- the logger configuration options to enable audit logs. Wonderful! You are now ready to start customizing your service! Read next section to learn how. ### Folder structure + The folder structure should follow this pattern: . @@ -165,6 +181,7 @@ It creates: - the `handler.test.js` file, that contains the Jest unit tests for the handler. ### Decorators + The template includes a set of default of request and reply decorators. The [decorators API][fastify-decorators] allows customization of the core Fastify objects, such as the server instance itself and any request and reply objects used during the HTTP request lifecycle. The decorators can be modified and extended with domain-specific notation. The template contains request and reply decorators for, respectively, enrichment of the request object with additional metadata (e.g. `requestId`) and error management. The template implements the formatter for the most common HTTP errors, allowing to have a common format for the error response that, by default, is the following: @@ -189,6 +206,80 @@ async function handler(request, reply) { } ``` +### Audit Trail + +This template provides out-of-the-box support for audit logs, which are designed to track meaningful events happening inside and across your microservices for auditing purposes. + +Audit logs are a subset of application logs with a custom logging level and expected to contain structured information, that can be later queried to answer common questions about systems and users activities and behaviors. + +The audit log configuration is specified at the bottom of the `index.js` file: + +```js +module.exports.options = { + logger: { + customLevels: { + audit: AUDIT_TRAIL_LOG_LEVEL, + }, + }, +} +``` + +The exported options enable you to generate audit logs by calling the `audit` logging method on the logger instance inside your handlers: + +```js +async function handler(request, reply) { + request.log.audit({ event: 'MiaCare/HelloWorld/v1', severity: 'INFO' }, 'Hello World Audit Log') +} +``` + +The first argument should be an object containing event metadata, that are persisted on MongoDB to performs advanced queries. + +Under the hood, audit logs have a custom log level which is used to filter them from other application logs. +By default, the log level is named `audit` and has `1100` as numeric value. +Setting a log level strictly greater than 1000 serves the purpose of avoid conflicts with existing log levels and ensure the audit logs are correctly filtered downstream and forwarded to MongoDB. + +:::danger + +Be careful when setting the `LOG_LEVEL` environment variable of your service: you must ensure that the numeric value associated to the chosen log level is lower than the one chosen for the audit log level, otherwise the audit logs will not be generated. + +::: + +So, given the example above, the resulting log on MongoDB will have a structure looking like this: + +```json +{ + "version": "1.0.0", + "timestamp": "2024-04-30T09:12:06.095Z", + "checksum": { + "algorithm": "sha512", + "value": "e474e95adfb31ef4cac7d992732a43d65e3313c852bd5e318dd84087b39ab62b19ff4c5590a6d5d5055ee5e3669c384c55eff0f36fe090205bd67d92d4aa9381" + }, + "metadata": { + "level": 1100, + "msg": "Hello World Audit Log", + "event": "MiaCare/HelloWorld/v1", + "severity": "INFO" + }, + "message": "Hello World Audit Log", + "rawLog": "{\"level\":1100,\"msg\":\"Hello World Audit Log\", ...}" +} +``` + +The audit logs are enriched with several fields and converted to a canonical form before being stored into MongoDB: + +- `version`: the version of the audit logs reference schema; +- `timestamp`: when the audit log was recorded; +- `checksum`: this checksum is generated automatically from the original log (available in the `rawLog` field); +- `metadata`: this field contains all the log fields, including the ones passed as first argument to the logger; +- `message`: this field contains the original log message (currently the message must be in the log `msg` field); +- `rawLog`: the original log, as emitted by the application logger. + +:::tip + +If you need to record when the even occurred, you should pass it explicitly as field of the object passed as first argument to the logger, so it's recorded in the metadata and available later for querying. + +::: + ## Expose an endpoint to your microservice In order to access to your new microservice it is necessary to create an endpoint that targets it. Follow [this link][mia-console-design-endpoints] to learn how to create an endpoint from the DevOps Console. @@ -228,6 +319,7 @@ Congratulations! You can now start developing your own NodeJS microservice! [fastify-plugins]: https://www.fastify.io/docs/latest/Reference/Plugins/ [github-jira-prepare-commit-msg]: https://github.com/bk201-/jira-prepare-commit-msg [husky]: https://typicode.github.io/husky/ + [mia-console-paas]: https://console.cloud.mia-platform.eu/login [mia-console-create-microservice]: /development_suite/api-console/api-design/services.md#how-to-create-a-microservice-from-an-example-or-from-a-template [mia-console-deploy]: /development_suite/deploy/overview.md diff --git a/static/docs_files_to_download/node.js-mia-care-samd-template/audit_logs.json b/static/docs_files_to_download/node.js-mia-care-samd-template/audit_logs.json new file mode 100644 index 0000000000..3e3b093c1a --- /dev/null +++ b/static/docs_files_to_download/node.js-mia-care-samd-template/audit_logs.json @@ -0,0 +1 @@ +[{"name":"_id","description":"_id","type":"ObjectId","required":true,"nullable":false},{"name":"creatorId","description":"creatorId","type":"string","required":true,"nullable":false},{"name":"createdAt","description":"createdAt","type":"Date","required":true,"nullable":false},{"name":"updaterId","description":"updaterId","type":"string","required":true,"nullable":false},{"name":"updatedAt","description":"updatedAt","type":"Date","required":true,"nullable":false},{"name":"__STATE__","description":"__STATE__","type":"string","required":true,"nullable":false},{"name":"version","type":"string","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false},{"name":"timestamp","type":"Date","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false},{"name":"severity","type":"string","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false},{"name":"metadata","type":"RawObject","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false},{"name":"checksum","type":"RawObject","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false},{"name":"message","type":"string","required":false,"nullable":false,"sensitivityValue":0,"encryptionEnabled":false,"encryptionSearchable":false}] \ No newline at end of file diff --git a/static/docs_files_to_download/therapy-and-monitoring-manager/detections.json b/static/docs_files_to_download/therapy-and-monitoring-manager/detections.json index fe5e7a429e..8b241c66a6 100644 --- a/static/docs_files_to_download/therapy-and-monitoring-manager/detections.json +++ b/static/docs_files_to_download/therapy-and-monitoring-manager/detections.json @@ -1,39 +1,45 @@ [ - { "name": "_id", "description": "_id", "type": "ObjectId", "required": true, "nullable": false }, + { + "name": "_id", + "type": "ObjectId", + "required": true, + "nullable": false, + "description": "_id" + }, { "name": "creatorId", - "description": "creatorId", "type": "string", "required": true, - "nullable": false + "nullable": false, + "description": "creatorId" }, { "name": "createdAt", - "description": "createdAt", "type": "Date", "required": true, - "nullable": false + "nullable": false, + "description": "createdAt" }, { "name": "updaterId", - "description": "updaterId", "type": "string", "required": true, - "nullable": false + "nullable": false, + "description": "updaterId" }, { "name": "updatedAt", - "description": "updatedAt", "type": "Date", "required": true, - "nullable": false + "nullable": false, + "description": "updatedAt" }, { "name": "__STATE__", - "description": "__STATE__", "type": "string", "required": true, - "nullable": false + "nullable": false, + "description": "__STATE__" }, { "name": "planType", @@ -62,15 +68,6 @@ "encryptionEnabled": false, "encryptionSearchable": false }, - { - "name": "observedAt", - "type": "Date", - "required": true, - "nullable": false, - "sensitivityValue": 0, - "encryptionEnabled": false, - "encryptionSearchable": false - }, { "name": "doctorId", "type": "string", @@ -98,13 +95,40 @@ "encryptionEnabled": false, "encryptionSearchable": false }, + { + "name": "observedAt", + "type": "Date", + "required": true, + "nullable": false, + "sensitivityValue": 0, + "encryptionEnabled": false, + "encryptionSearchable": false + }, { "name": "deviceId", "type": "string", - "required": true, + "required": false, + "nullable": false, + "sensitivityValue": 0, + "encryptionEnabled": false, + "encryptionSearchable": false + }, + { + "name": "thresholds", + "type": "Array_RawObject", + "required": false, + "nullable": false, + "sensitivityValue": 0, + "encryptionEnabled": false, + "encryptionSearchable": false + }, + { + "name": "thresholdsExceeded", + "type": "boolean", + "required": false, "nullable": false, "sensitivityValue": 0, "encryptionEnabled": false, "encryptionSearchable": false } -] +] \ No newline at end of file