From 3199038b7e58adef2a08f42a0cb2f435aa2869de Mon Sep 17 00:00:00 2001 From: Andra Blaj Date: Fri, 3 Oct 2025 14:26:21 +0300 Subject: [PATCH 1/5] chore(#1790): replace relref with link render hooks --- content/en/building/branding/publishing.md | 2 +- .../building/contact-management/contacts.md | 6 +++--- .../forms/_partial_expression_functions.md | 2 +- content/en/building/forms/app.md | 6 +++--- .../en/building/forms/configuring/uhc-mode.md | 2 +- content/en/building/forms/contact.md | 4 ++-- .../building/interoperability/cht-config.md | 2 +- content/en/building/local-setup.md | 8 ++++---- content/en/building/login.md | 2 +- content/en/building/navigation.md | 6 +++--- .../en/building/privacy-policies/_index.md | 2 +- content/en/building/reference/api.md | 10 +++++----- .../building/reference/app-settings/_index.md | 2 +- .../reference/app-settings/header_tabs.md | 2 +- .../reference/app-settings/outbound.md | 4 ++-- .../reference/app-settings/patient_reports.md | 2 +- .../reference/app-settings/registrations.md | 2 +- .../reference/app-settings/schedules.md | 2 +- .../supervision/chw-aggregate-targets.md | 4 ++-- .../supervision/dashboards-reporting.md | 2 +- .../supervision/supervision-overview.md | 2 +- .../supervision/user-area-management.md | 2 +- content/en/building/tasks/tasks-overview.md | 4 ++-- .../en/building/training/onboarding/_index.md | 6 +++--- .../training-cards-resources/_index.md | 6 +++--- .../training/training-cards/_index.md | 8 ++++---- .../training-cards-configuration.md | 12 +++++------ .../en/building/training/training-instance.md | 4 ++-- content/en/building/training/training.md | 4 ++-- .../en/building/training/users-bulk-load.md | 10 +++++----- .../tutorials/application-settings.md | 12 +++++------ .../tutorials/multi-facility-users.md | 12 +++++------ content/en/building/uhc-mode/configuring.md | 2 +- .../code/android/development-setup.md | 4 ++-- .../contributing/code/core/automated-tests.md | 2 +- .../contributing/code/core/dev-environment.md | 4 ++-- .../secure-sharing-of-developer-instance.md | 6 +++--- .../contributing/code/core/using-windows.md | 2 +- .../code/test-data/csv-to-docs.md | 2 +- .../code/troubleshooting/obtaining-logs.md | 2 +- .../replicating-production-data-locally.md | 2 +- .../disclosing-vulnerabilities.md | 2 +- content/en/hosting/_index.md | 4 ++-- content/en/hosting/analytics/_index.md | 2 +- .../hosting/analytics/building-dbt-models.md | 12 +++++------ .../couch2pg-to-cht-sync-migration.md | 16 +++++++-------- content/en/hosting/analytics/dashboards.md | 2 +- .../analytics/environment-variables.md | 6 +++--- .../hosting/analytics/setup-docker-compose.md | 16 +++++++-------- .../en/hosting/analytics/setup-kubernetes.md | 10 +++++----- content/en/hosting/analytics/tuning-dbt.md | 4 ++-- content/en/hosting/cht/_index.md | 6 +++--- content/en/hosting/cht/app-developer.md | 8 ++++---- content/en/hosting/cht/considerations.md | 6 +++--- content/en/hosting/cht/docker/_index.md | 2 +- .../cht/docker/adding-tls-certificates.md | 2 +- content/en/hosting/cht/docker/backups.md | 8 ++++---- content/en/hosting/cht/docker/installation.md | 6 +++--- .../en/hosting/cht/kubernetes-vs-docker.md | 2 +- content/en/hosting/cht/kubernetes/_index.md | 2 +- .../hosting/cht/migration/preparing-for-4.md | 12 +++++------ content/en/hosting/cht/requirements.md | 6 +++--- .../en/hosting/cht/upgrade-troubleshooting.md | 2 +- content/en/hosting/couch2pg/couch2pg-setup.md | 2 +- .../medic/data-migration-3x-eks-to-4x-eks.md | 2 +- content/en/hosting/monitoring/integration.md | 20 +++++++++---------- content/en/hosting/monitoring/introduction.md | 4 ++-- .../en/hosting/monitoring/postgres-ingest.md | 14 ++++++------- content/en/hosting/monitoring/production.md | 2 +- content/en/hosting/monitoring/setup.md | 6 +++--- content/en/reference-apps/maternal-newborn.md | 2 +- content/en/releases/4_11_0.md | 2 +- content/en/releases/4_12_0.md | 8 ++++---- content/en/releases/4_19_0.md | 2 +- content/en/releases/4_2_0.md | 12 +++++------ content/en/releases/4_3_0.md | 4 ++-- content/en/releases/4_5_0.md | 2 +- content/en/releases/4_6_0.md | 2 +- content/en/releases/4_7_0.md | 2 +- .../architecture/cht-android.md | 2 +- .../architecture/cht-conf.md | 2 +- .../architecture/cht-core.md | 2 +- .../architecture/cht-interoperability.md | 2 +- .../architecture/cht-sync.md | 4 ++-- .../architecture/cht-watchdog.md | 6 +++--- .../architecture/overview.md | 8 ++++---- .../concepts/offline-first.md | 2 +- content/en/technical-overview/concepts/pwa.md | 2 +- .../analytics/data-flows-for-analytics.md | 2 +- 89 files changed, 217 insertions(+), 217 deletions(-) diff --git a/content/en/building/branding/publishing.md b/content/en/building/branding/publishing.md index f82ec47cc3..e10275f83b 100644 --- a/content/en/building/branding/publishing.md +++ b/content/en/building/branding/publishing.md @@ -70,4 +70,4 @@ Other MDM providers include [Headwind MDM](https://h-mdm.com/) and [Microsoft In ### Progressive Web App -Another alternative is to install the CHT Core webapp as a Progressive Web App. This avoids building an Android application altogether. Read more on the [PWA page]({{< relref "technical-overview/concepts/pwa" >}}). +Another alternative is to install the CHT Core webapp as a Progressive Web App. This avoids building an Android application altogether. Read more on the [PWA page](/technical-overview/concepts/pwa). diff --git a/content/en/building/contact-management/contacts.md b/content/en/building/contact-management/contacts.md index 7c07fd2b59..e07f0c0a67 100644 --- a/content/en/building/contact-management/contacts.md +++ b/content/en/building/contact-management/contacts.md @@ -41,7 +41,7 @@ Because this list defaults to show the “places” below the user in the hierar New “places” can be added to this level of the hierarchy by clicking on the “Add new +” button at the bottom of the screen. This allows a CHW to add a new family to their list, or a CHW supervisor to add a new Area they manage. -With the [_UHC Mode_]({{< relref "building/uhc-mode" >}}) configured, the main list of households is displayed as shown on the rightmost screenshot to help health workers ensure that all households are visited regularly. +With the [_UHC Mode_](/building/uhc-mode) configured, the main list of households is displayed as shown on the rightmost screenshot to help health workers ensure that all households are visited regularly. ## Searching @@ -126,7 +126,7 @@ Health workers can use these Care Guides at any time. If the app has scheduled a ## Creating and Editing Contacts -Contacts are created/modified via [contact forms]({{< relref "building/forms/contact" >}}). These forms are highly configurable and allow for specifying detailed workflows for capturing information about contacts. +Contacts are created/modified via [contact forms](/building/forms/contact). These forms are highly configurable and allow for specifying detailed workflows for capturing information about contacts. ### Duplicate Contact Detection @@ -140,6 +140,6 @@ One major challenge when collecting contact data is ensuring users do not inadve The CHT also supports automatically detecting when a contact being created or edited by a user matches an existing contact record. If a duplicate contact is detected, the user will be given the option of proceeding to the profile of the existing contact. Alternatively, the user can choose to override the duplicate detection logic and continue creating/editing the contact as originally intended. -The matching logic for duplicate detection is [configurable]({{< relref "building/forms/contact#properties" >}}) and can be tuned to the specific needs and data structures of a particular project. The algorithm compares the created/edited contact _to its sibling contacts._ These are other contacts of the same type that share the same parent contact. By default, contacts are considered duplicates if they have very similar names AND (for persons) if they are the same age (in years). This default logic can be overridden with custom logic for each type of contact. +The matching logic for duplicate detection is [configurable](/building/forms/contact#properties) and can be tuned to the specific needs and data structures of a particular project. The algorithm compares the created/edited contact _to its sibling contacts._ These are other contacts of the same type that share the same parent contact. By default, contacts are considered duplicates if they have very similar names AND (for persons) if they are the same age (in years). This default logic can be overridden with custom logic for each type of contact. diff --git a/content/en/building/forms/_partial_expression_functions.md b/content/en/building/forms/_partial_expression_functions.md index 699a05e918..8eff9f976d 100644 --- a/content/en/building/forms/_partial_expression_functions.md +++ b/content/en/building/forms/_partial_expression_functions.md @@ -13,7 +13,7 @@ The following functions are available for use in JavaScript expressions: | `ageInMonth(contact)` | Returns the current age of the given contact in months. | | `ageInYears(contact)` | Returns the current age of the given contact in years. | | `levenshteinEq(string0, string1, threshold = 3)` | _(Added `4.19.0`)_ Returns `true` if the [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance) between the given strings is less than or equal to the given threshold. Otherwise `false`. | -| `normalizedLevenshteinEq(string0, string1, threshold = 0.42857142857142855)` | _(Added `4.19.0`)_ Similar to the `levenshteinEq` function except the distance value is "normalized" (by dividing by the length of the longest string) before comparing to the threshold. [See below]({{< relref "#normalized-levenshtein-equality" >}}) for more details. | +| `normalizedLevenshteinEq(string0, string1, threshold = 0.42857142857142855)` | _(Added `4.19.0`)_ Similar to the `levenshteinEq` function except the distance value is "normalized" (by dividing by the length of the longest string) before comparing to the threshold. [See below](/#normalized-levenshtein-equality) for more details. | #### Normalized Levenshtein Equality diff --git a/content/en/building/forms/app.md b/content/en/building/forms/app.md index baf7e36df4..0dc9cfa726 100644 --- a/content/en/building/forms/app.md +++ b/content/en/building/forms/app.md @@ -359,7 +359,7 @@ Some fields in app forms control specific aspects of CHT Apps, either to bring d The `NationalQuintile` and `UrbanQuintile` fields on a form will be assigned to all people belonging to the place. This is helpful when household surveys have quintile information which could be used to target health services for individuals. {{< see-also prefix="Read More" page="building/forms/configuring/wealth-quintiles" >}} ### UHC Mode -When the `visited_contact_uuid` field is set at the top level of a form, this form is counted as a household visit in [UHC Mode]({{< relref "building/uhc-mode" >}}). This field must be a `calculate` field with the place UUID of the visited contact. You may run into performance issues if you configure this to look at forms submitted very frequently. {{< see-also prefix="Read More" page="building/forms/configuring/uhc-mode" >}} +When the `visited_contact_uuid` field is set at the top level of a form, this form is counted as a household visit in [UHC Mode](/building/uhc-mode). This field must be a `calculate` field with the place UUID of the visited contact. You may run into performance issues if you configure this to look at forms submitted very frequently. {{< see-also prefix="Read More" page="building/forms/configuring/uhc-mode" >}} ## Uploading Binary Attachments @@ -375,8 +375,8 @@ The meta information in the `{form_name}.properties.json` file defines the form' | property | description | required | |---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---| -| `title`| The form's title seen in the app. Uses a localization array using the 2-letter code, not the translation keys discussed in the [Localization section]({{< relref "building/translations/localizing" >}}). | yes | -| `icon` | Icon associated with the form. The value is the image's key in the `resources.json` file, as described in the [Icons section]({{< relref "building/branding/resources#icons" >}}) | yes | +| `title`| The form's title seen in the app. Uses a localization array using the 2-letter code, not the translation keys discussed in the [Localization section](/building/translations/localizing). | yes | +| `icon` | Icon associated with the form. The value is the image's key in the `resources.json` file, as described in the [Icons section](/building/branding/resources#icons) | yes | | `subject_key` | Override the default report list title with a custom translation key. The translation uses a summary of the report as the evaluation context so you can include report fields in your value, for example: `Case registration {{case_id}}`. Useful properties available in the summary include: `from` (the phone number of the sender), `phone` (the phone number of the report contact), `form` (the form code), `subject.name` (the name of the subject), and `case_id` (the generated case id). Defaults to the name of the report subject. | no | | `hidden_fields` | Array of Strings of form fields to hide in the view report UI in the app. This is only applied to future reports and will not change how existing reports are displayed. | no | | `context` | The context defines when and where the form should be available in the app | no | diff --git a/content/en/building/forms/configuring/uhc-mode.md b/content/en/building/forms/configuring/uhc-mode.md index 4aafdd905b..aa9a9559eb 100644 --- a/content/en/building/forms/configuring/uhc-mode.md +++ b/content/en/building/forms/configuring/uhc-mode.md @@ -13,7 +13,7 @@ aliases: - /apps/guides/forms/uhc-mode --- -The CHT's [UHC Mode]({{< relref "building/uhc-mode" >}}) empowers CHWs to provide equitable and timely care to families in their catchment area. The Community Health Toolkit supports this use-case by displaying the number of visits made to a household and highlighting households which haven't met their visit goal in red at the top of the contact list. +The CHT's [UHC Mode](/building/uhc-mode) empowers CHWs to provide equitable and timely care to families in their catchment area. The Community Health Toolkit supports this use-case by displaying the number of visits made to a household and highlighting households which haven't met their visit goal in red at the top of the contact list. {{< cards >}} {{< figure src="UHC.gif" link="UHC.gif" alt="UHC Mode screenshot" class="right col-6 col-lg-3" >}} diff --git a/content/en/building/forms/contact.md b/content/en/building/forms/contact.md index 2b6250d3c2..bac4f269c6 100644 --- a/content/en/building/forms/contact.md +++ b/content/en/building/forms/contact.md @@ -55,10 +55,10 @@ The meta information in the `{contact_type_id}-{create|edit}.properties.json` fi | Property | Description | required | |------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| | `context` | _Added in `3.10`._ The contact form context defines when the form should be available in the app. Note: this applies only to the contact form, not the contacts themselves. | no | -| `context.expression` | A JavaScript expression evaluated when a contact profile is viewed. This can limit which users have access to the contact form. [See below]({{< relref "#context-expression" >}}) for more details. | no | +| `context.expression` | A JavaScript expression evaluated when a contact profile is viewed. This can limit which users have access to the contact form. [See below](/#context-expression) for more details. | no | | `context.permission` | String permission key required to allow the user to view and submit this form. If blank, this defaults to allowing all access. | no | | `duplicate_check` | _Added in `4.19`._ Allows for configuring or disabling the [duplicate detection logic]({{< ref "building/contact-management/contacts#duplicate-contact-detection" >}}) for a particular contact type. | no | -| `duplicate_check.expression` | A JavaScript expression evaluated when submitting the contact form. The expression defines the logic used for determining when a contact is considered to be a duplicate. [See below]({{< relref "#duplicate-check-expression" >}}) for more details. | no | +| `duplicate_check.expression` | A JavaScript expression evaluated when submitting the contact form. The expression defines the logic used for determining when a contact is considered to be a duplicate. [See below](/#duplicate-check-expression) for more details. | no | | `duplicate_check.disabled` | Boolean determining if the duplicate check should be run when submitting this contact form. Default is `false`. | no | #### Context Expression diff --git a/content/en/building/interoperability/cht-config.md b/content/en/building/interoperability/cht-config.md index a0af3fe821..57ec7cb5fc 100644 --- a/content/en/building/interoperability/cht-config.md +++ b/content/en/building/interoperability/cht-config.md @@ -172,7 +172,7 @@ In this example, a `danger signs` question is converted into `Observations` wher ## Inbound Patients It is also possbile to create patients in the CHT from patients that were created in external systems. -Patients in CHT applications are represented as [contacts]({{< relref "/building/contact-management/contacts" >}}), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`. +Patients in CHT applications are represented as [contacts](//building/contact-management/contacts), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`. To create data in CHT, a mediator converts a FHIR `Patient` to a json object that it submits as a request to [the records API](/building/reference/api/#records). This requires a [form](/building/reference/app-settings/forms/) to be configured in the CHT; the incoming data will be saved as a report. diff --git a/content/en/building/local-setup.md b/content/en/building/local-setup.md index f7ae47ddea..efde5f5f18 100644 --- a/content/en/building/local-setup.md +++ b/content/en/building/local-setup.md @@ -38,7 +38,7 @@ CHT apps can be built on your local system (with the necessary libraries install Before you begin, ensure you have the following tools: - [git](https://git-scm.com/downloads) or the [Github Desktop](https://desktop.github.com/) -- [docker and docker compose]({{< relref "/hosting/cht/requirements#docker" >}}). +- [docker and docker compose](//hosting/cht/requirements#docker). ### Installing Docker @@ -106,7 +106,7 @@ Using python on your terminal, install `pyxform` globally using the command belo sudo python3 -m pip install git+https://github.com/medic/pyxform.git@medic-conf-1.17#egg=pyxform-medic ``` -If you encounter the error `npm ERR! gyp ERR verb find Python Python is not set` while installing pyxform and are running macOS, see [this troubleshooting section]({{< relref "community/contributing/code/core/dev-environment#macos--123" >}}). +If you encounter the error `npm ERR! gyp ERR verb find Python Python is not set` while installing pyxform and are running macOS, see [this troubleshooting section](/community/contributing/code/core/dev-environment#macos--123). #### `cht-conf` @@ -170,7 +170,7 @@ To open a terminal running on you _host environment_ in VS Code, open the Comman When using `cht-conf` within a Docker container to connect to a CHT instance that is running on your local machine (e.g. a development instance), you cannot use the `--local` flag or `localhost` in your `--url` parameter (since these will be interpreted as "local to the container"). -It is recommended to run a local CHT instance using the [CHT Docker Helper script]({{< relref "/hosting/cht/app-developer#cht-docker-helper-for-4x" >}}). You can connect to the resulting `...local-ip.medicmobile.org` URL from the Docker container (or the VS Code terminal). (Just make sure the port your CHT instance is hosted on is not blocked by your firewall). +It is recommended to run a local CHT instance using the [CHT Docker Helper script](//hosting/cht/app-developer#cht-docker-helper-for-4x). You can connect to the resulting `...local-ip.medicmobile.org` URL from the Docker container (or the VS Code terminal). (Just make sure the port your CHT instance is hosted on is not blocked by your firewall). --- @@ -178,7 +178,7 @@ It is recommended to run a local CHT instance using the [CHT Docker Helper scrip Now that you have the dependent tools and software installed, you are ready to set up your local CHT environment. -Refer to the [App Developer Hosting Guide]({{< relref "/hosting/cht/app-developer" >}}) for instructions on how to deploy a local CHT instance. +Refer to the [App Developer Hosting Guide](//hosting/cht/app-developer) for instructions on how to deploy a local CHT instance. Note that the first time you run your CHT instance it may take a while. In case you run into issues running your docker file, ensure that the following setting in Docker is checked. > Settings >> General >> Use Docker Compose V2 diff --git a/content/en/building/login.md b/content/en/building/login.md index 9184b0aad7..ec736ed284 100644 --- a/content/en/building/login.md +++ b/content/en/building/login.md @@ -38,7 +38,7 @@ To enhance the security of CHT applications, users logging in for the first time {{< figure src="password-change.png" link="password-change.png" class="col-12 col-lg-12" >}} This feature is enabled by default because it encourages best practices. However, only new users will be prompted to go through this flow or those users whose passwords have been reset by the system administration. -Projects can disable this feature by enabling the `can_skip_password_change` [permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}}). This permission is a [feature flag]({{< relref "/community/contributing/code/core/feature-flags" >}}) and will be removed in a later CHT release. +Projects can disable this feature by enabling the `can_skip_password_change` [permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}}). This permission is a [feature flag](//community/contributing/code/core/feature-flags) and will be removed in a later CHT release. Subsequent logins won’t require a password change – if the app closes before changing the password, the user will be prompted again when they reopen it. If a user is unable to update their password, they won’t be able to access the app. diff --git a/content/en/building/navigation.md b/content/en/building/navigation.md index 3804a3df80..9ca7aff2c6 100644 --- a/content/en/building/navigation.md +++ b/content/en/building/navigation.md @@ -39,7 +39,7 @@ Tap the menu icon in the upper right corner of the header to access other pages, {{< figure src="sync-status.png" link="sync-status.png" class="right col-6 col-lg-4" >}} -Data synchronization is important for [offline users]({{< relref "building/users" >}}). These users keep a copy of the data they have access to on their device. They can work from their device while disconnected from the internet (offline), by reading from and writing to their copy of the data. “Sync” (synchronization) is when data on the device is made to match the data on the server and requires an internet connection. The CHT app monitors the online status and attempts sync accordingly. +Data synchronization is important for [offline users](/building/users). These users keep a copy of the data they have access to on their device. They can work from their device while disconnected from the internet (offline), by reading from and writing to their copy of the data. “Sync” (synchronization) is when data on the device is made to match the data on the server and requires an internet connection. The CHT app monitors the online status and attempts sync accordingly. #### Replication Types @@ -50,7 +50,7 @@ Synchronization consists of upward replication and downward replication. The CHT application manages data synchronization across two types of databases: - **Main Application Database (`medic`)**: The main database that stores the primary data used by the application. It includes contacts, reports, messages, and other critical documents necessary for the core functionality of the application. This database is synchronized continuously to reflect changes to the application, such as new contact creations. Each user stores a subset of the main database which includes only the documents they're allowed to view. -- **User-Metadata Database(`medic-user-{username}-meta`)**: Each user has a dedicated database that stores operational metadata, including [telemetry data]({{< relref "technical-overview/data/performance/telemetry" >}}) and error messages. Synchronization occurs at predefined intervals to ensure up-to-date monitoring and analysis. +- **User-Metadata Database(`medic-user-{username}-meta`)**: Each user has a dedicated database that stores operational metadata, including [telemetry data](/technical-overview/data/performance/telemetry) and error messages. Synchronization occurs at predefined intervals to ensure up-to-date monitoring and analysis. #### Sync Status Notification @@ -92,4 +92,4 @@ Introduced in 4.20.0 {{< figure src="storage_pressure_screenshot.svg" link="storage_pressure_screenshot.svg" >}} -Another important factor for [offline users]({{< relref "building/users" >}}) is the amount of storage available on their device. The CHT app will not continue to function if a user runs out of storage space. The storage pressure indicator in the menu drawer shows users, at a glance, how much free disk space they have left. +Another important factor for [offline users](/building/users) is the amount of storage available on their device. The CHT app will not continue to function if a user runs out of storage space. The storage pressure indicator in the menu drawer shows users, at a glance, how much free disk space they have left. diff --git a/content/en/building/privacy-policies/_index.md b/content/en/building/privacy-policies/_index.md index 0de2055f26..1ae53d5e27 100644 --- a/content/en/building/privacy-policies/_index.md +++ b/content/en/building/privacy-policies/_index.md @@ -38,7 +38,7 @@ There are two ways to add or edit a privacy policy: cht --local upload-privacy-policies ``` -2. Update and view privacy policies in the [Admin Console]({{< relref "building/admin" >}}), under `Display` > `Privacy Policies` +2. Update and view privacy policies in the [Admin Console](/building/admin), under `Display` > `Privacy Policies` > [!NOTE] > - Use language codes when associating HTML files to languages diff --git a/content/en/building/reference/api.md b/content/en/building/reference/api.md index eb8850f85d..20cd5f2e8c 100644 --- a/content/en/building/reference/api.md +++ b/content/en/building/reference/api.md @@ -236,7 +236,7 @@ Returns a JSON array of CHT-related software versions and device information for |-----------------|------------------------------------------------------------------------------------------------------------------------------------------|-------------| | user | The user's name. | CHT 4.7.0 | | deviceId | The unique key for the user's device. | CHT 4.7.0 | -| date | The date the telemetry entry was taken in YYYY-MM-DD, see [relevant docs]({{< relref "technical-overview/data/performance/telemetry" >}}). | CHT 4.7.0 | +| date | The date the telemetry entry was taken in YYYY-MM-DD, see [relevant docs](/technical-overview/data/performance/telemetry). | CHT 4.7.0 | | browser.name | The name of the browser used. | CHT 4.7.0 | | browser.version | The version of the browser used. | CHT 4.7.0 | | apk | The Internal [version code](https://developer.android.com/reference/android/R.styleable#AndroidManifest_versionCode) of the Android app. | CHT 4.7.0 | @@ -521,7 +521,7 @@ Endpoint used by cht-gateway to send sms messages. More documentation in the [ch ### POST /api/v1/sms/{aggregator}/{endpoint} -Endpoint for integration with SMS aggregators. More details on the [RapidPro]({{< relref "building/messaging/gateways/rapidpro" >}}) and [Africa's Talking]({{< relref "building/messaging/gateways/africas-talking" >}}) pages. +Endpoint for integration with SMS aggregators. More details on the [RapidPro](/building/messaging/gateways/rapidpro) and [Africa's Talking](/building/messaging/gateways/africas-talking) pages. ## Contact @@ -2128,7 +2128,7 @@ To regenerate the token, update the user sending `token_login` with a `true` val | false | existent, no token | None. | | false | existent, with token | Request requires a password. Login by SMS is disabled. Old token is invalidated. Existent sessions are invalidated. | -This feature uses [`app_settings.app_url`]({{< relref "building/reference/app-settings/#app_settingsjson" >}}) and [`app_settings.token_login`]({{< relref "building/reference/app-settings/token_login.md" >}}) to be defined and enabled. +This feature uses [`app_settings.app_url`](/building/reference/app-settings/#app_settingsjson) and [`app_settings.token_login`](/building/reference/app-settings/token_login.md) to be defined and enabled. If `app_settings.app_url` is not defined, the generated token-login URL will use the `Host` request header, which may not always be correct. {{< see-also page="building/login" anchor="remote-login" >}} @@ -2149,7 +2149,7 @@ When creating/editing users via the [App Management interface]({{< ref "building ##### Locale for SSO users -When a user logs in via SSO, the CHT app will attempt to localize the interface based on the `locale` claim returned by the OIDC Provider (otherwise it will fall back to the default locale configured as the first `languages` entry in the [`app_settings.json`]({{< relref "building/reference/app-settings/#app_settingsjson" >}})). +When a user logs in via SSO, the CHT app will attempt to localize the interface based on the `locale` claim returned by the OIDC Provider (otherwise it will fall back to the default locale configured as the first `languages` entry in the [`app_settings.json`](/building/reference/app-settings/#app_settingsjson)). {{< see-also page="/hosting/sso" anchor="remote-login" >}} @@ -2973,7 +2973,7 @@ Content-Type: application/json ## Monitoring -See the [Monitoring and alerting on the CHT]({{< relref "/hosting/monitoring" >}}) page for how to use this API in production. +See the [Monitoring and alerting on the CHT](//hosting/monitoring) page for how to use this API in production. ### GET /api/v1/monitoring diff --git a/content/en/building/reference/app-settings/_index.md b/content/en/building/reference/app-settings/_index.md index b0db51c2b1..82f3b25162 100644 --- a/content/en/building/reference/app-settings/_index.md +++ b/content/en/building/reference/app-settings/_index.md @@ -51,7 +51,7 @@ The following settings do not need to be specified. They should only be defined | task_days_overdue | Display number of overdue days in tasks list | false | 3.13.0 | | languages | Array of objects with `locale` and `enabled` properties representing respectively the 2 or 3 letter language code and whether that language should be enabled.
If unset it falls back to the previous behavior of relying on the `enabled` property of each translation document `messages-XX.properties`. This fallback behavior is now deprecated and will be removed in the next major version (5.0). This `languages` configuration property will be required for CHT 5.0+. | | 4.2.0 | | place_hierarchy_types | Array of contact types' IDs, should match the ones defined in `contact_types`. This is used to define the Place Filter's options in Reports tab. | | 2.15.0 | -| assetlinks | Array of [Digital Asset Links]({{< relref "assetlinks" >}}) definitions. This is used to associate your CHT instance's domain to your Android app to verify app links. | | 4.7.0 | +| assetlinks | Array of [Digital Asset Links](/assetlinks) definitions. This is used to associate your CHT instance's domain to your Android app to verify app links. | | 4.7.0 | ## SMS Workflows diff --git a/content/en/building/reference/app-settings/header_tabs.md b/content/en/building/reference/app-settings/header_tabs.md index 9276502bdf..27d697ee45 100644 --- a/content/en/building/reference/app-settings/header_tabs.md +++ b/content/en/building/reference/app-settings/header_tabs.md @@ -46,7 +46,7 @@ These values can also be changed from the Admin console, on the Images page unde | property | type | required | description | | -------- | ---- | -------- | ----------- | | `icon` | string | no | [FontAwesome](https://fontawesome.com/v4.7.0/) icon name | -| `resource_icon` | string | no | [Resource icon]({{< relref "building/branding/resources" >}}) name. +| `resource_icon` | string | no | [Resource icon](/building/branding/resources) name. > [!NOTE] > Selected Resource icons take precedence over selected FontAwesome icons. diff --git a/content/en/building/reference/app-settings/outbound.md b/content/en/building/reference/app-settings/outbound.md index cb22bbf810..f0c8ef642b 100644 --- a/content/en/building/reference/app-settings/outbound.md +++ b/content/en/building/reference/app-settings/outbound.md @@ -199,7 +199,7 @@ Example: you want the system to send outbound pushes based on a cron schedule ev #### Troubleshooting -By default, Sentinel will log a message each time an outbound request is sent indicating if the request was successful or not. If you are having trouble getting your outbound requests to work, you can [enable debug logging]({{< relref "/hosting/cht/docker/logs#setting-log-level" >}}) to get more information about the exact contents of the request/response. +By default, Sentinel will log a message each time an outbound request is sent indicating if the request was successful or not. If you are having trouble getting your outbound requests to work, you can [enable debug logging](//hosting/cht/docker/logs#setting-log-level) to get more information about the exact contents of the request/response. ## How Outbound messages are sent @@ -247,4 +247,4 @@ Outbound may send your request multiple times even if the user just hit save onc ## Inbound? -The outbound feature is used for sending data to an external service. If you are looking to **receive** data from an external service, take a look at [the records api]({{< relref "building/reference/api#records" >}}). +The outbound feature is used for sending data to an external service. If you are looking to **receive** data from an external service, take a look at [the records api](/building/reference/api#records). diff --git a/content/en/building/reference/app-settings/patient_reports.md b/content/en/building/reference/app-settings/patient_reports.md index 209d476abe..3bb0e7a99b 100644 --- a/content/en/building/reference/app-settings/patient_reports.md +++ b/content/en/building/reference/app-settings/patient_reports.md @@ -34,7 +34,7 @@ The `patient_reports` key contains the actions to take when reports about people |`messages`|An array of automated responses to incoming reports.|no| |`messages[].translation_key`|Translation key for the message text associated with this event|no| |`messages[].event_type`|An event that will trigger sending of this message. Typical values are: `report_accepted` when the report has been successfully validated, `registration_not_found` when the shortcode (patient ID or place ID) supplied in the report doesn't match any shortcode issued by Medic. `on_mute` and `on_unmute` are used in the context of muting as described [here]({{% ref "building/reference/app-settings/transitions#muting" %}})|no| -|`messages[].recipient`|Who the message should be sent to. Use `reporting_unit` for the sender of the report, `clinic` for clinic contact, and `parent` for the parent contact. [See SMS Recipients]({{< relref "building/reference/app-settings/_index.md#sms-recipient-resolution" >}})|no| +|`messages[].recipient`|Who the message should be sent to. Use `reporting_unit` for the sender of the report, `clinic` for clinic contact, and `parent` for the parent contact. [See SMS Recipients](/building/reference/app-settings/_index.md#sms-recipient-resolution)|no| ## Code sample diff --git a/content/en/building/reference/app-settings/registrations.md b/content/en/building/reference/app-settings/registrations.md index 1ffb1950ec..bb09a2a90a 100644 --- a/content/en/building/reference/app-settings/registrations.md +++ b/content/en/building/reference/app-settings/registrations.md @@ -33,7 +33,7 @@ The `registrations` key contains actions that need to be performed for incoming |`messages`|An array of automated responses to incoming reports.|no| |`messages[].translation_key`|Translation key for the message text associated with this event.|no| |`messages[].event_type`|An event that will trigger sending of this message. Typical values are: `report_accepted` when the report has been successfully validated and `registration_not_found` when the shortcode (patient ID or place ID) supplied in the report doesn't match any shortcode issued by Medic.|no| -|`messages[].recipient`|Who the message should be sent to. Use `reporting_unit` for the sender of the report, `clinic` for clinic contact, and `parent` for the parent contact. [See SMS Recipients]({{< relref "building/reference/app-settings/_index.md#sms-recipient-resolution" >}})|no| +|`messages[].recipient`|Who the message should be sent to. Use `reporting_unit` for the sender of the report, `clinic` for clinic contact, and `parent` for the parent contact. [See SMS Recipients](/building/reference/app-settings/_index.md#sms-recipient-resolution)|no| ## Code sample diff --git a/content/en/building/reference/app-settings/schedules.md b/content/en/building/reference/app-settings/schedules.md index aaef2b7232..e47a7f62ee 100644 --- a/content/en/building/reference/app-settings/schedules.md +++ b/content/en/building/reference/app-settings/schedules.md @@ -32,7 +32,7 @@ The `schedules` key contains an array of schedule objects, each representing the |`messages[].offset`| Time interval from the `start_from` date for when the message should be sent. It is structured as a string with an integer value followed by a space and the time unit. For instance `8 weeks` or `2 days`. The units available are `seconds`, `minutes`, `hours`, `days`, `weeks`, `months`, `years`, and their singular forms as well. Note that although you can specify `seconds`, the accuracy of the sending time will be determined by delays in the processing the message on the server and on the gateway.|yes| |`messages[].send_day`| String value of the day of the week on which the message should be sent. For instance, to send a message at the beginning of the week setting it to `"Monday"` will make sure the message goes out on the closest Monday _after_ the `start_date` + `offset`. |no| |`messages[].send_time`| Time of day that the message should be sent in 24 hour format.|no| -|`messages[].recipient`| Recipient of the message. It can be set to `reporting_unit` (sender of the form), `clinic` (clinic that the sender of the form is attached to), `parent` (parent of the sender of the form), or a specific phone number. [See SMS Recipients]({{< relref "building/reference/app-settings/_index.md#sms-recipient-resolution" >}})|no| +|`messages[].recipient`| Recipient of the message. It can be set to `reporting_unit` (sender of the form), `clinic` (clinic that the sender of the form is attached to), `parent` (parent of the sender of the form), or a specific phone number. [See SMS Recipients](/building/reference/app-settings/_index.md#sms-recipient-resolution)|no| ## Code Sample diff --git a/content/en/building/supervision/chw-aggregate-targets.md b/content/en/building/supervision/chw-aggregate-targets.md index a2caac0b5b..7eadb46102 100644 --- a/content/en/building/supervision/chw-aggregate-targets.md +++ b/content/en/building/supervision/chw-aggregate-targets.md @@ -9,7 +9,7 @@ description: > {{< figure src="aggregate-supervisor.png" link="aggregate-supervisor.png" class="right col-7 col-lg-6" >}} -For CHW Supervisors, the [Targets]({{< relref "building/targets/targets-overview" >}}) tab provides important insights into their community unit. It presents Supervisors with actionable information about their CHWs, by aggregating data for each of the CHWs that a Supervisor manages and presenting it in an easily digestible format. This enables Supervisors to gain insight into how well their team of CHWs is working together to meet common goals. +For CHW Supervisors, the [Targets](/building/targets/targets-overview) tab provides important insights into their community unit. It presents Supervisors with actionable information about their CHWs, by aggregating data for each of the CHWs that a Supervisor manages and presenting it in an easily digestible format. This enables Supervisors to gain insight into how well their team of CHWs is working together to meet common goals. Selecting an aggregate widget opens the detailed view with the data for each individual CHW. If a CHW is performing below the target goal, their value will be highlighted in red, making it easier for Supervisors to know with which CHWs to follow up for coaching and performance management. @@ -67,5 +67,5 @@ Filtering the Aggregate Targets by **Reporting Period** adds the name of the pre > - The list of facilities in the sidebar are sorted in alphabetic order. > - The default filter option for the facilities filter is the first facility in the sorted `array` of user Facilities. > - The default filter option for the reporting period is `This month`. -> - The facility filter label in this example (Health Facility) is the `name_key` of the facility `contact_type` configured in the the [app-settings]({{< relref "building/reference/app-settings/hierarchy" >}}) +> - The facility filter label in this example (Health Facility) is the `name_key` of the facility `contact_type` configured in the the [app-settings](/building/reference/app-settings/hierarchy) > - The reporting period label in this example (Reporting Period) is added as a translation key `analytics.target.aggregates.reporting_period`. diff --git a/content/en/building/supervision/dashboards-reporting.md b/content/en/building/supervision/dashboards-reporting.md index c09cb07281..fb67e66f10 100644 --- a/content/en/building/supervision/dashboards-reporting.md +++ b/content/en/building/supervision/dashboards-reporting.md @@ -17,7 +17,7 @@ The data that can be visualized is highly configurable, and depends on what data ## DHIS2 Data Verification -Supervisors often provide a critical bridge between CHWs and broader health system reporting. Using the CHT’s [DHIS2 integration]({{< relref "building/integrations/dhis2" >}}), Supervisors can see the aggregate of each DHIS2 Data Value across all CHWs in their area. By tapping on a target, they can also see each CHW’s contribution towards that total. Once the Supervisor has verified data accuracy with CHWs, they can communicate with Health Records Information Officers to feed data into the national health information system. +Supervisors often provide a critical bridge between CHWs and broader health system reporting. Using the CHT’s [DHIS2 integration](/building/integrations/dhis2), Supervisors can see the aggregate of each DHIS2 Data Value across all CHWs in their area. By tapping on a target, they can also see each CHW’s contribution towards that total. Once the Supervisor has verified data accuracy with CHWs, they can communicate with Health Records Information Officers to feed data into the national health information system. {{< callout type="info" >}} DHIS2 integration was introduced in v3.9. diff --git a/content/en/building/supervision/supervision-overview.md b/content/en/building/supervision/supervision-overview.md index fb9a1950a9..9dac151e70 100644 --- a/content/en/building/supervision/supervision-overview.md +++ b/content/en/building/supervision/supervision-overview.md @@ -9,4 +9,4 @@ description: > Supervision and workforce management are important aspects to building and maintaining high-performing community health systems. Supervisors help Community Health Workers deliver quality healthcare services to their patients through building CHW care delivery knowledge and skills, fostering a supportive work environment, and supporting continuity of care between home-based care and community health centers or facilities. -The importance of regular and systematic CHW supervision is emphasized by the WHO’s [guidelines](https://www.who.int/publications/i/item/9789241550369) on health policy and system support, which is formulated to optimize community-based health worker programs. Following these guidelines, the CHT is designed to enable Supervisors to provide personalized performance feedback during CHW supervision as well as track aggregate statistics. Data collected from completed [Care Guides]({{< relref "building/care-guides" >}}) produce granular information which can be used to provide coaching that promotes compliance with health program standards of practice and closer monitoring of outcomes. +The importance of regular and systematic CHW supervision is emphasized by the WHO’s [guidelines](https://www.who.int/publications/i/item/9789241550369) on health policy and system support, which is formulated to optimize community-based health worker programs. Following these guidelines, the CHT is designed to enable Supervisors to provide personalized performance feedback during CHW supervision as well as track aggregate statistics. Data collected from completed [Care Guides](/building/care-guides) produce granular information which can be used to provide coaching that promotes compliance with health program standards of practice and closer monitoring of outcomes. diff --git a/content/en/building/supervision/user-area-management.md b/content/en/building/supervision/user-area-management.md index 67e3010aa7..2f34068901 100644 --- a/content/en/building/supervision/user-area-management.md +++ b/content/en/building/supervision/user-area-management.md @@ -10,7 +10,7 @@ description: > ## User Management Supervisors are able to set up users in the CHT without contacting a system administrator. They can **create** new CHW user accounts or **replace** CHWs on an existing device. -When _creating_ a new user account, Supervisors fill out the necessary details, including the CHW's phone number, from their own device. They can do this while offline, but must sync before the actual user account is created. Once the Supervisor syncs, the CHT will send an SMS to the new CHW with a [magic link]({{< relref "building/login#magic-links-for-logging-in-token-login" >}}) that enables them to login and start using the app. +When _creating_ a new user account, Supervisors fill out the necessary details, including the CHW's phone number, from their own device. They can do this while offline, but must sync before the actual user account is created. Once the Supervisor syncs, the CHT will send an SMS to the new CHW with a [magic link](/building/login#magic-links-for-logging-in-token-login) that enables them to login and start using the app. When _replacing_ a CHW, Supervisors access the existing device and provide details about the new CHW. The new CHW can start using the app immediately, even while offline, and will see all of the existing household data. Once the new CHW syncs, the records on the server will be updated to reflect the new CHWs details. diff --git a/content/en/building/tasks/tasks-overview.md b/content/en/building/tasks/tasks-overview.md index 99dd9ab57c..60fcb9d68d 100644 --- a/content/en/building/tasks/tasks-overview.md +++ b/content/en/building/tasks/tasks-overview.md @@ -76,7 +76,7 @@ When a CHW clicks on a task, the care guide configured for that task displays. C {{< card link="tasks-care4.png" image="tasks-care4.png" method="resize">}} {{< /cards >}} -Find more information on how [care guides]({{< relref "building/care-guides" >}}) provide decision support for healthcare workers. +Find more information on how [care guides](/building/care-guides) provide decision support for healthcare workers. When the user completes the care guide, the task will be cleared from the Tasks tab, and the report will be accessible from the Reports page or on the profile of the person or place whom the report is about. @@ -86,7 +86,7 @@ When the user completes the care guide, the task will be cleared from the Tasks {{< card link="tasks-household.png" image="tasks-household.png" method="resize">}} {{< /cards >}} -Alternatively, there is an option to configure Household Tasks. When this [permission]({{< relref "building/reference/app-settings/user-permissions" >}}) is enabled, once a CHW has completed a task, they are taken to the Other Household Tasks page. This page shows the CHW all the additional outstanding tasks within the same household in which the initial task was completed. +Alternatively, there is an option to configure Household Tasks. When this [permission](/building/reference/app-settings/user-permissions) is enabled, once a CHW has completed a task, they are taken to the Other Household Tasks page. This page shows the CHW all the additional outstanding tasks within the same household in which the initial task was completed. CHWs are able to complete tasks directly from this page, or exit by tapping on the “X”. If the household has no additional tasks, they will return directly to the main task list. diff --git a/content/en/building/training/onboarding/_index.md b/content/en/building/training/onboarding/_index.md index 7fd3e871f7..85ffbf9346 100644 --- a/content/en/building/training/onboarding/_index.md +++ b/content/en/building/training/onboarding/_index.md @@ -15,11 +15,11 @@ aliases: When onboarding new users, having a dedicated CHT app and instance for training can be helpful; it allows new users to do training exercises with mock data to get familiar with the app, while not having the data from their training interfering with the future use of their CHT app. Different approaches are possible, such as only entering real patient data during training, or manually deleting all the training data, but these methods are less practical for large deployments. > [!NOTE] -> The suggestions in this guide should be assessed and adapted as needed to benefit a deployment. It is important that users don't accidentally use the wrong app. The [troubleshooting guide]({{< relref "building/training/training-instance" >}}) can help to monitor and remediate training data being in the production instance, or the opposite. +> The suggestions in this guide should be assessed and adapted as needed to benefit a deployment. It is important that users don't accidentally use the wrong app. The [troubleshooting guide](/building/training/training-instance) can help to monitor and remediate training data being in the production instance, or the opposite. ## Setting up a training app -A separate Android App can be created for training, which would point to a CHT instance dedicated to training. The training instance should have the same configuration as the production instance, and have users created for training. To differentiate the Android app used for training from the production one, create a duplicate of [your flavor]({{< relref "building/branding/android" >}}) and modify the following aspects +A separate Android App can be created for training, which would point to a CHT instance dedicated to training. The training instance should have the same configuration as the production instance, and have users created for training. To differentiate the Android app used for training from the production one, create a duplicate of [your flavor](/building/branding/android) and modify the following aspects - **Border & Message**: Consider adding a distinctive border and message when using the training app. This can be done by setting the build config field `IS_TRAINING_APP` to `true`, as seen in [`build.gradle`](https://github.com/medic/cht-android/blob/8d077ed08dc3889ef1f4e3bad7231931bca55d87/build.gradle#L212-L216) for the training version of the Gamma app. - **CHT Instance**: In your flavor's `res/values/strings.xml` file set the `app_host` string to be the URL of your training instance, as seen in the [Gamma Training app](https://github.com/medic/cht-android/blob/8d077ed08dc3889ef1f4e3bad7231931bca55d87/src/medicmobilegamma_training/res/values/strings.xml#L3). If left the same as the production app both training and production data will end up in your production instance. - **Launcher icons**: Consider using completely different icons, or at least change the color of the launcher icons. @@ -41,4 +41,4 @@ If the production app can always be installed after the use of the training is c Changing passwords for the training users in an attempt to lock them out is not recommended. In some circumstances a user would be able to continue to use the training app for production use and not have the data sync back to the server. -It is preferable to remove the training app from devices, and [monitor the training instance for unexpected activity]({{< relref "building/training/training-instance" >}}) that can be brought over to the production instance if needed. +It is preferable to remove the training app from devices, and [monitor the training instance for unexpected activity](/building/training/training-instance) that can be brought over to the production instance if needed. diff --git a/content/en/building/training/training-cards-resources/_index.md b/content/en/building/training/training-cards-resources/_index.md index 04353e0a68..ac429b6d79 100644 --- a/content/en/building/training/training-cards-resources/_index.md +++ b/content/en/building/training/training-cards-resources/_index.md @@ -14,7 +14,7 @@ aliases: ## Best practices -If you are deploying new [trainings cards]({{< relref "building/training/training-cards" >}}), here are some best practices to follow: +If you are deploying new [trainings cards](/building/training/training-cards), here are some best practices to follow: - When deploying training cards for the first time, provide guidance in advance as to what users should expect from the cards and how to use them - Test training card content with a small set of users to ensure learnability and understanding before deploying to your live instance @@ -32,7 +32,7 @@ Some examples of data to monitor include: ## Examples -Below is a list of training cards that you can use in your project to train users about new updates in CHT. Read the [step by step guide]({{< relref "building/training/training-cards" >}}) to deploy the training cards. +Below is a list of training cards that you can use in your project to train users about new updates in CHT. Read the [step by step guide](/building/training/training-cards) to deploy the training cards. ### Floating Action Button @@ -58,6 +58,6 @@ Get the training card files [here](https://github.com/medic/cht-docs/tree/main/c -Once you have downloaded the training card files, follow the [step by step guide]({{< relref "building/training/training-cards" >}}) to learn how to edit the `properties file` to configure: +Once you have downloaded the training card files, follow the [step by step guide](/building/training/training-cards) to learn how to edit the `properties file` to configure: - The `roles` of users who can view the training cards - The `start_date` to define the training start day (when the training cards should show) diff --git a/content/en/building/training/training-cards/_index.md b/content/en/building/training/training-cards/_index.md index 9854fb98e3..0ee601901e 100644 --- a/content/en/building/training/training-cards/_index.md +++ b/content/en/building/training/training-cards/_index.md @@ -15,9 +15,9 @@ aliases: _Introduced in 4.2.0_ -*Training Cards* help health workers learn about changes to CHT apps remotely, directly in their app. Training content might include information about a newly deployed feature, changes to a [care guide]({{< relref "building/care-guides" >}}), or simply a reminder about an underused feature or workflow. They are perfect for training on a very specific topic and are not meant to replace a comprehensive onboarding program. +*Training Cards* help health workers learn about changes to CHT apps remotely, directly in their app. Training content might include information about a newly deployed feature, changes to a [care guide](/building/care-guides), or simply a reminder about an underused feature or workflow. They are perfect for training on a very specific topic and are not meant to replace a comprehensive onboarding program. -[Template training content]({{< relref "building/training/training-cards-resources" >}}) for new CHT features is made available from time to time. These templates can be customized to the local context. +[Template training content](/building/training/training-cards-resources) for new CHT features is made available from time to time. These templates can be customized to the local context. {{< figure src="training-deck.png" link="training-deck.png" class="col-12 col-lg-10" >}} @@ -35,11 +35,11 @@ Training materials can also be accessed in the training page found in the auxili ## Completing -Health workers read through each card one by one in a predefined sequence, tapping “Next” on each card. When they are finished reading all cards, they tap “Submit” on the last card. The training set is now considered complete and they can continue using their app. Completed training sets show up on the [main list]({{< relref "building/reports/#main-list" >}}) of the Reports tab and they won’t be asked to complete this set again. If there are additional training sets to complete, they will be shown the next day the app is opened. +Health workers read through each card one by one in a predefined sequence, tapping “Next” on each card. When they are finished reading all cards, they tap “Submit” on the last card. The training set is now considered complete and they can continue using their app. Completed training sets show up on the [main list](/building/reports/#main-list) of the Reports tab and they won’t be asked to complete this set again. If there are additional training sets to complete, they will be shown the next day the app is opened. ## Monitoring -As mentioned above, completed training sets will show up on the [main list]({{< relref "building/reports/#main-list" >}}) of the Reports tab. These reports are available in [analytics]({{< relref "building/supervision/#supervisor-dashboards" >}}), [aggregate targets]({{< relref "building/supervision/#chw-aggregate-targets" >}}) , and can trigger supervision workflows and [tasks]({{< relref "building/supervision/#supervisor-tasks" >}}). +As mentioned above, completed training sets will show up on the [main list](/building/reports/#main-list) of the Reports tab. These reports are available in [analytics](/building/supervision/#supervisor-dashboards), [aggregate targets](/building/supervision/#chw-aggregate-targets) , and can trigger supervision workflows and [tasks](/building/supervision/#supervisor-tasks). ## Configurability Training cards can be shown to any user associated to a contact. A “set” of training cards represents a collection of individual training cards, generally covering a single training topic. The list below highlights some of the key areas of customization: diff --git a/content/en/building/training/training-cards/training-cards-configuration.md b/content/en/building/training/training-cards/training-cards-configuration.md index 63bfb9ca68..f35383d654 100644 --- a/content/en/building/training/training-cards/training-cards-configuration.md +++ b/content/en/building/training/training-cards/training-cards-configuration.md @@ -15,14 +15,14 @@ aliases: - /apps/guides/training/training-cards/ --- -[Training Cards]({{< relref "building/training/training-cards" >}}) enable remote training from within the CHT by showing a sequence of "cards" containing content provided by App Developers. The content might include information about a newly deployed feature, changes to a [care guide]({{< relref "building/care-guides" >}}), or simply a reminder about an underused feature or workflow. Enketo forms are used to display the content, and App Developers can specify a start date, duration, and to which [user roles]({{< relref "building/reference/app-settings/user-roles" >}}) the cards should be shown. Like [app forms]({{< relref "building/forms/app" >}}), forms used by training cards will automatically be downloaded to the user’s devices. +[Training Cards](/building/training/training-cards) enable remote training from within the CHT by showing a sequence of "cards" containing content provided by App Developers. The content might include information about a newly deployed feature, changes to a [care guide](/building/care-guides), or simply a reminder about an underused feature or workflow. Enketo forms are used to display the content, and App Developers can specify a start date, duration, and to which [user roles](/building/reference/app-settings/user-roles) the cards should be shown. Like [app forms](/building/forms/app), forms used by training cards will automatically be downloaded to the user’s devices. > [!NOTE] -> Example training forms are available [here]({{< relref "building/training/training-cards-resources" >}}) and provide a good starting point. +> Example training forms are available [here](/building/training/training-cards-resources) and provide a good starting point. # Step 1: Create the training form -Create an [XLS Form]({{< relref "building/forms/app#xlsform" >}}). In the following example, the training form is called `my_new_feature`, it has some text in the `label::en` column, and some images in the column `media::images` to illustrate the feature. +Create an [XLS Form](/building/forms/app#xlsform). In the following example, the training form is called `my_new_feature`, it has some text in the `label::en` column, and some images in the column `media::images` to illustrate the feature. {{< figure src="step-1-xls-form.png" link="step-1-xls-form.png" class="left col-10" >}} @@ -38,7 +38,7 @@ Important, define the `form_id` located in the `settings` sheet with the prefix # Step 3: Configure the training form -Create a [properties file]({{< relref "building/forms/form-properties#3-define-the-forms-context" >}}) to define the starting date of the training, the number of days it will be active, and the user roles that can access the training. In our example, the file name is `my_new_feature.properties.json` and contains the following properties: +Create a [properties file](/building/forms/form-properties#3-define-the-forms-context) to define the starting date of the training, the number of days it will be active, and the user roles that can access the training. In our example, the file name is `my_new_feature.properties.json` and contains the following properties: ``` { @@ -66,7 +66,7 @@ In the example above, the training cards could be shown to any user with the "nu If your training form has images, create a folder with the same name as the form and add `-media` suffix. In our example, the form name is `my_new_feature`, then the folder name should be `my_new_feature-media`. -Inside that new folder, make another one called images and put inside all the `images` that your form needs. See more about [multimedia in forms]({{< relref "building/forms/configuring/multimedia" >}}). +Inside that new folder, make another one called images and put inside all the `images` that your form needs. See more about [multimedia in forms](/building/forms/configuring/multimedia). # Step 5: Put everything in the right place @@ -107,7 +107,7 @@ cht --url=http://admin-user:secretpass@my-xyz-project.org upload-training-forms At this point the training cards are ready to use. You can verify by logging in with a user that has a valid role assigned for the training card, on the day that the training starts. Remember, to sync the app to see the results (the uncompleted training will display once a day). -Using [telemetry]({{< relref "technical-overview/data/performance/telemetry" >}}) you can monitor user interaction with each training card "set". Some key metrics you can view include: +Using [telemetry](/technical-overview/data/performance/telemetry) you can monitor user interaction with each training card "set". Some key metrics you can view include: 1. Number of times each user was presented with training cards 2. The date(s) each user was presented with training cards diff --git a/content/en/building/training/training-instance.md b/content/en/building/training/training-instance.md index e509525c4e..e1fb6cc1fd 100644 --- a/content/en/building/training/training-instance.md +++ b/content/en/building/training/training-instance.md @@ -10,7 +10,7 @@ aliases: - /building/guides/data/training-instance --- -After [onboarding CHWs]({{< relref "building/training/onboarding" >}}), sometimes data ends up on the wrong CHT instance. There are some passive and active actions you can take to help deal with this situation. +After [onboarding CHWs](/building/training/onboarding), sometimes data ends up on the wrong CHT instance. There are some passive and active actions you can take to help deal with this situation. ## Monitoring`` @@ -56,7 +56,7 @@ A limitation of this technique is that CHWs who have not synchronized their devi ### CHT based supervisor tasks -[Tasks for supervisors]({{< relref "building/supervision#supervisor-tasks" >}}) can also be used for the CHWs that report to them. This can be used to trigger a task when a CHW hasn't submitted a task within a given period on production. +[Tasks for supervisors](/building/supervision#supervisor-tasks) can also be used for the CHWs that report to them. This can be used to trigger a task when a CHW hasn't submitted a task within a given period on production. ## Remediation diff --git a/content/en/building/training/training.md b/content/en/building/training/training.md index 7aa7ffb56a..4554e21cbc 100644 --- a/content/en/building/training/training.md +++ b/content/en/building/training/training.md @@ -26,7 +26,7 @@ The CHT training process comprises a series of steps highlighted below that need * Define the training objectives - In this step, the training outcomes are defined, these are things end users should be able to do as a result of the training. * Develop a training plan or checklist - The checklist lists the tasks, activities and resources needed to train the end users * Create the training materials and resources -* Conduct the training - Different training approaches can be adopted. Training can be done in person or virtually. It includes direct training of end users, training of trainers (ToT) model which involves training program champions to cascade the training, use of [CHT training cards]({{< relref "building/training/training-cards" >}}) in which users are able to access training resources in-app, remote online training and self learning through a learning management system. +* Conduct the training - Different training approaches can be adopted. Training can be done in person or virtually. It includes direct training of end users, training of trainers (ToT) model which involves training program champions to cascade the training, use of [CHT training cards](/building/training/training-cards) in which users are able to access training resources in-app, remote online training and self learning through a learning management system. * Evaluate the training - In this stage, the training outcomes are assessed to determine if the training has achieved the expected outcomes. The learning objectives will help to determine the evaluation process that would be most appropriate. ## Pre training preparation @@ -43,7 +43,7 @@ Before training is done, a training preparation checklist is prepared to ensure * Identify the total number of participants. It is recommended that the ratio of facilitators to participants should be 1:10 and each training class should have a maximum of 30 participants. * Confirm and organize training venue. The venue should be well ventilated, have adequate lighting, good sanitation and security and be at a central location for easy access. It is recommended that the training of the CHWs takes place in a community setting such as schools, churches or mosques while training of CHAs and program teams can happen in a facility or hotel. * Phone preparation - * Procure phones for the training with [minimum specs requirements]({{< relref "building/login" >}}) + * Procure phones for the training with [minimum specs requirements](/building/login) * Ensure phones are fully charged prior to training * Guide users on how to obtain and register SIM cards * Load airtime into phones diff --git a/content/en/building/training/users-bulk-load.md b/content/en/building/training/users-bulk-load.md index 6354fc705a..0f58097373 100644 --- a/content/en/building/training/users-bulk-load.md +++ b/content/en/building/training/users-bulk-load.md @@ -17,7 +17,7 @@ relatedContent: > --- {{< callout >}} - The bulk user upload feature is available in 3.16.0 and later versions of the CHT. As of CHT 3.17.0, when creating both a contact and a place, the contact will be set as the default contact of the place. User creation can be scripted using the [CHT API]({{< relref "building/reference/api#post-apiv2users" >}}) directly or using the [`cht-conf` tool](https://github.com/medic/cht-conf), which is detailed in the [CSV-to-Docs guide]({{< relref "/community/contributing/code/test-data/csv-to-docs" >}}). + The bulk user upload feature is available in 3.16.0 and later versions of the CHT. As of CHT 3.17.0, when creating both a contact and a place, the contact will be set as the default contact of the place. User creation can be scripted using the [CHT API](/building/reference/api#post-apiv2users) directly or using the [`cht-conf` tool](https://github.com/medic/cht-conf), which is detailed in the [CSV-to-Docs guide](//community/contributing/code/test-data/csv-to-docs). This feature can be used to load as many users as possible but works optimally with chunks of 1,000 users or less. {{< /callout >}} @@ -43,8 +43,8 @@ Click on any of the use cases below to make a copy of the spreadsheet for the us We will use the second use case to create user accounts and their contacts in the example below. ## Contact Spreadsheet Instructions -The spreadsheet interfaces with the [`POST /api/v1/users` API]({{< relref "building/reference/api#get-apiv1users" >}}) which works as though passing a JSON array of users. Rows in the spreadsheet represent a user while columns represent properties of the user. -Each column in the spreadsheet maps to an object property understood by the API to insert the users into the database. These properties can be found in [the Users API documentation]({{< relref "building/reference/api#post-apiv1users" >}}). +The spreadsheet interfaces with the [`POST /api/v1/users` API](/building/reference/api#get-apiv1users) which works as though passing a JSON array of users. Rows in the spreadsheet represent a user while columns represent properties of the user. +Each column in the spreadsheet maps to an object property understood by the API to insert the users into the database. These properties can be found in [the Users API documentation](/building/reference/api#post-apiv1users). Contact spreadsheets are named according to the user role, for example when creating users who are chws and others who are chw_supervisors, the following contact spreadsheets are populated respectively: "contact.chw" and "contact.chw_supervisor". @@ -155,7 +155,7 @@ Add some new rows at the bottom (item 1), enter the new place name in column A ( ## Configuring custom places types -The third use case mentioned in the [workbook instructions section]({{< relref "#workbook-instructions" >}}) links to a Google Sheets to create user places alongside their account and their contact. This works out of the box with the `default` CHT configuration but will require adjustments to be made in the `place.type_VLOOKUP` spreadsheet when dealing with a CHT configuration with custom places types. +The third use case mentioned in the [workbook instructions section](/#workbook-instructions) links to a Google Sheets to create user places alongside their account and their contact. This works out of the box with the `default` CHT configuration but will require adjustments to be made in the `place.type_VLOOKUP` spreadsheet when dealing with a CHT configuration with custom places types. The `place.type_VLOOKUP` spreadsheet has two columns that contain the name of the places types set in the [`.contact_types[]`]({{< relref "building/reference/app-settings/hierarchy" >}}) property of your `app_settings.json` and their respective IDs. The place type name is used by the `User-Place-Type:excluded` column in the `contact.chw` spreadsheet to provide a user-friendly way to pick a place with autocompletion. You will want to keep this spreadsheet in sync with your CHT configuration to create users' places. @@ -167,7 +167,7 @@ If you have miss-matched contact types, you will get an error upon import: > **Wrong type, this is not a person.** -As of CHT 3.7.0, you're [allowed to declare different contact types]({{< relref "building/reference/app-settings/hierarchy#app_settingsjson-contact_types" >}}) in your `app_settings.json`. If you have populated the `.contact_types[]` property in your JSON, you will need to update the automatic value of the `contact.contact_type` column. The default value is: +As of CHT 3.7.0, you're [allowed to declare different contact types](/building/reference/app-settings/hierarchy#app_settingsjson-contact_types) in your `app_settings.json`. If you have populated the `.contact_types[]` property in your JSON, you will need to update the automatic value of the `contact.contact_type` column. The default value is: ```shell =if(NOT(ISBLANK(D2)),"person","") diff --git a/content/en/building/tutorials/application-settings.md b/content/en/building/tutorials/application-settings.md index 90ed3550c5..8bb701b51e 100644 --- a/content/en/building/tutorials/application-settings.md +++ b/content/en/building/tutorials/application-settings.md @@ -24,15 +24,15 @@ App settings allow you to both persist information that is critical to the appli ## Brief Overview of Key Concepts -The settings which control CHT apps are defined in the *[app_settings.json]({{< relref "building/reference/app-settings" >}})* file, and stored in the settings doc in the database. +The settings which control CHT apps are defined in the *[app_settings.json](/building/reference/app-settings)* file, and stored in the settings doc in the database. -*[Permissions]({{< relref "building/users#permissions" >}})* are settings that control access to specific app features and functionality. +*[Permissions](/building/users#permissions)* are settings that control access to specific app features and functionality. -*[Roles]({{< relref "building/users#roles" >}})* define permissions for users to access a group of app features and functionality. +*[Roles](/building/users#roles)* define permissions for users to access a group of app features and functionality. -*[Replication]({{< relref "technical-overview/data/performance/replication" >}})* is when users download a copy of the data on to their device. *Replication depth* refers to the number of levels within a hierarchy a specific user role is able to replicate. +*[Replication](/technical-overview/data/performance/replication)* is when users download a copy of the data on to their device. *Replication depth* refers to the number of levels within a hierarchy a specific user role is able to replicate. -*[Transitions]({{< relref "building/reference/app-settings/transitions" >}})* are Javascript code that run when a document is changed. A transition can edit the changed doc or do anything server side code can do for that matter. +*[Transitions](/building/reference/app-settings/transitions)* are Javascript code that run when a document is changed. A transition can edit the changed doc or do anything server side code can do for that matter. ## Required Resources @@ -104,7 +104,7 @@ In this example, the `generate_patient_id_on_people` and `death_reporting` trans You can configure hierarchies by editing the object corresponding to the `"contact_types"` key in `app_settings.json`. The following code sample represents the default hierarchy configuration. You can modify existing contact types by editing the objects within the array. When configuring a new deployment, it's important to plan your hierarchy well. While there are no limits in the CHT to the hierarchical depth or breadth it will support, there are some trade-offs and caveats: -* While it is possible to [update the hierarchy configuration]({{< relref "building/contact-management/moving-contacts" >}}) after launch it can be difficult and potentially disruptive to users. Try and avoid this by planning ahead as best as possible. +* While it is possible to [update the hierarchy configuration](/building/contact-management/moving-contacts) after launch it can be difficult and potentially disruptive to users. Try and avoid this by planning ahead as best as possible. * If your hierarchy is too shallow, users will download more docs than are necessary for their work which will impact the performance of the app. Taking the time to get the hierarchy configuration right makes it easy to give users access to only the docs they need. **Important Note on Creating and Editing Contacts:** The ability to create and edit contacts in the CHT, including person entities, is dependent on the presence of corresponding forms in the `forms/contact` directory. Each contact type, such as "person", "clinic", "health_center", etc., must have associated `create` and `edit` forms defined. Without these forms, the functionality to add or modify these contact types in the CHT application will not be available. Ensure that the necessary forms are created and correctly referenced in the `app_settings.json` file under their respective contact type definitions. For guidance on creating these contact forms, refer to the [CHT documentation on contact forms](https://docs.communityhealthtoolkit.org/building/reference/forms/contact/). diff --git a/content/en/building/tutorials/multi-facility-users.md b/content/en/building/tutorials/multi-facility-users.md index ab14dbf7b1..8201acc75a 100644 --- a/content/en/building/tutorials/multi-facility-users.md +++ b/content/en/building/tutorials/multi-facility-users.md @@ -20,20 +20,20 @@ This tutorial covers: - Creating places and assign contacts to those places - Assigning users to multiple places -The [CHT application settings]({{< relref "building/tutorials/application-settings" >}}) allows you to both persist information that is critical to the application outside the code, and to create profiles that store the preferences for project deployments. +The [CHT application settings](/building/tutorials/application-settings) allows you to both persist information that is critical to the application outside the code, and to create profiles that store the preferences for project deployments. ## Brief Overview of Key Concepts -*[Permissions]({{< relref "building/users#permissions" >}})* are settings that control access to specific app features and functionality. +*[Permissions](/building/users#permissions)* are settings that control access to specific app features and functionality. -*[Roles]({{< relref "building/users#roles" >}})* define permissions for users to access a group of app features and functionality. +*[Roles](/building/users#roles)* define permissions for users to access a group of app features and functionality. -*[Contacts]({{< relref "building/contact-management" >}})* are people or places that are created in the CHT application. +*[Contacts](/building/contact-management)* are people or places that are created in the CHT application. -*[People]({{< relref "building/contact-management" >}})* are both patients in the system and users of the system, such as CHWs or Nurses. +*[People](/building/contact-management)* are both patients in the system and users of the system, such as CHWs or Nurses. -*[Places]({{< relref "building/contact-management" >}})* represent either an actual physical location such as a health facility, clinic, or a grouping such as a household or CHW Area. +*[Places](/building/contact-management)* represent either an actual physical location such as a health facility, clinic, or a grouping such as a household or CHW Area. ## Pre-requisites diff --git a/content/en/building/uhc-mode/configuring.md b/content/en/building/uhc-mode/configuring.md index 46a424e557..2824a0815a 100644 --- a/content/en/building/uhc-mode/configuring.md +++ b/content/en/building/uhc-mode/configuring.md @@ -7,4 +7,4 @@ description: > Configurability of the UHC Mode --- -The last visited date is calculated based on the number of days since an action was taken for that household, and the number of visits reflects the actions taken for that household in the current month. What constitutes as an action for a household, along with the start date for the reporting period, [are configurable]({{< relref "building/forms/configuring/uhc-mode" >}}) to CHT app developers. +The last visited date is calculated based on the number of days since an action was taken for that household, and the number of visits reflects the actions taken for that household in the current month. What constitutes as an action for a household, along with the start date for the reporting period, [are configurable](/building/forms/configuring/uhc-mode) to CHT app developers. diff --git a/content/en/community/contributing/code/android/development-setup.md b/content/en/community/contributing/code/android/development-setup.md index 81c7be86b5..769ff4f663 100644 --- a/content/en/community/contributing/code/android/development-setup.md +++ b/content/en/community/contributing/code/android/development-setup.md @@ -157,13 +157,13 @@ the submodules within the cht-android folder. _Only CHT Android_ -Refer to the [CHT Core Developer Guide]({{< relref "community/contributing/code/core/dev-environment#nginx-local-ip" >}}). +Refer to the [CHT Core Developer Guide](/community/contributing/code/core/dev-environment#nginx-local-ip). #### Manually testing with older Android versions _Only CHT Android_ -Later versions of the CHT, only support [running on Chrome/Webview 90+]({{< relref "releases/#dependencies" >}}). Some older versions of Android will not have a new enough Android System Webview to be able to run the CHT webapp. This is particularly true of emulated Android devices, which typically are configured to not receive updates. To test the CHT functionality on these devices you must manually upgrade the version of the Chrome/Webview apk used as the Android System Webview. +Later versions of the CHT, only support [running on Chrome/Webview 90+](/releases/#dependencies). Some older versions of Android will not have a new enough Android System Webview to be able to run the CHT webapp. This is particularly true of emulated Android devices, which typically are configured to not receive updates. To test the CHT functionality on these devices you must manually upgrade the version of the Chrome/Webview apk used as the Android System Webview. To upgrade the necessary apk on an emulated Android device: diff --git a/content/en/community/contributing/code/core/automated-tests.md b/content/en/community/contributing/code/core/automated-tests.md index ee7903f317..d3e8b95be9 100644 --- a/content/en/community/contributing/code/core/automated-tests.md +++ b/content/en/community/contributing/code/core/automated-tests.md @@ -334,7 +334,7 @@ You can contribute to the CHT testing in various ways: ### How to write automated e2e tests -Read the [style guide for automated tests]({{< relref "community/contributing/code/core/style-guide-automated-e2e-tests.md" >}}) for guidelines on how to create new automated test cases for CHT-Core. +Read the [style guide for automated tests](/community/contributing/code/core/style-guide-automated-e2e-tests.md) for guidelines on how to create new automated test cases for CHT-Core. ### Debugging E2E tests diff --git a/content/en/community/contributing/code/core/dev-environment.md b/content/en/community/contributing/code/core/dev-environment.md index c1b5c2baa6..ca93dd937e 100644 --- a/content/en/community/contributing/code/core/dev-environment.md +++ b/content/en/community/contributing/code/core/dev-environment.md @@ -11,9 +11,9 @@ aliases: --- {{< callout >}} -This guide assumes you are a CHT Core developer wanting to run the CHT Core from source code to make commits to the [public GitHub repository](https://github.com/medic/cht-core). To set up your environment for developing apps, see the [app guide]({{< relref "/hosting/cht/app-developer.md" >}}). +This guide assumes you are a CHT Core developer wanting to run the CHT Core from source code to make commits to the [public GitHub repository](https://github.com/medic/cht-core). To set up your environment for developing apps, see the [app guide](//hosting/cht/app-developer.md). -To deploy the CHT in production, see either [hosting section]({{< relref "/hosting/cht" >}}). +To deploy the CHT in production, see either [hosting section](//hosting/cht). {{< /callout >}} ## The Happy Path Installation diff --git a/content/en/community/contributing/code/core/secure-sharing-of-developer-instance.md b/content/en/community/contributing/code/core/secure-sharing-of-developer-instance.md index 327a8ff708..83346665e3 100644 --- a/content/en/community/contributing/code/core/secure-sharing-of-developer-instance.md +++ b/content/en/community/contributing/code/core/secure-sharing-of-developer-instance.md @@ -15,10 +15,10 @@ aliases: > > Never expose a development instance to the internet where you've replicated production data locally. Well, maybe not never, but with extreme care and intention. > -> Also not - if you only want to test with mobile devices that require a valid TLS certificate, do not use method. Instead, use [nginx-local-ip]({{< relref "community/contributing/code/core/dev-environment#nginx-local-ip" >}}) +> Also not - if you only want to test with mobile devices that require a valid TLS certificate, do not use method. Instead, use [nginx-local-ip](/community/contributing/code/core/dev-environment#nginx-local-ip) ## Overview -When using a local [development environment]({{< relref "community/contributing/code/core/dev-environment" >}}), you may want to share your work with other collaborators. By using a publicly accessible web server, you can receive the secure https requests and forward them back to your CHT instance which doesn't have https set up: +When using a local [development environment](/community/contributing/code/core/dev-environment), you may want to share your work with other collaborators. By using a publicly accessible web server, you can receive the secure https requests and forward them back to your CHT instance which doesn't have https set up: {{< figure src="/community/contributing/code/troubleshooting/obtaining-logs/SSH-tunnel-diagram.svg" caption="Path data flows from mobile device -> reverse proxy -> router -> developer" >}} @@ -27,7 +27,7 @@ Once you have this web server set up, you may continue to use it whenever you wa ## Prerequisites This guide assumes: -* You have a local [dev instance]({{< relref "community/contributing/code/core/dev-environment" >}}) set up of cht-core +* You have a local [dev instance](/community/contributing/code/core/dev-environment) set up of cht-core * You have the [generic Medic app](https://play.google.com/store/apps/details?id=org.medicmobile.webapp.mobile&hl=en_US) installed on your Android device. This version allows you to enter a custom CHT URL on first run. * You have an Ubuntu >18.04 server with a public IP and a DNS entry that you can SSH into and have sudo on * You have Apache >2.4.29 installed on the Ubuntu server and can add a new vhost to it, including an SSL cert. (nginx could be used instead as well, but not covered here) diff --git a/content/en/community/contributing/code/core/using-windows.md b/content/en/community/contributing/code/core/using-windows.md index a7226e751a..e676ddd18e 100644 --- a/content/en/community/contributing/code/core/using-windows.md +++ b/content/en/community/contributing/code/core/using-windows.md @@ -89,7 +89,7 @@ $: npm ci $: npm run build-dev-watch ``` -From this point, follow the `harden couch` section in [Core Developer Setup]({{< relref "community/contributing/code/core/dev-environment#cht-core-cloning-and-setup" >}}). +From this point, follow the `harden couch` section in [Core Developer Setup](/community/contributing/code/core/dev-environment#cht-core-cloning-and-setup). To get multiple linux terminals (so you can run `npm run`, `api` and `sentinel` at the same time) either install and use something like Tmux, or if you click `Ubuntu` in the Windows start menu again it will open up a new terminal in the same linux instance. diff --git a/content/en/community/contributing/code/test-data/csv-to-docs.md b/content/en/community/contributing/code/test-data/csv-to-docs.md index 800172933b..6c3915eb06 100644 --- a/content/en/community/contributing/code/test-data/csv-to-docs.md +++ b/content/en/community/contributing/code/test-data/csv-to-docs.md @@ -348,7 +348,7 @@ To fetch the files from Google Drive run the `fetch-csvs-from-google-drive` acti #### Linking to Google Drive -The file `csvs-on-google-drive.json` in your project's home directory will consist of a key value pair for each CSV file. The keys must be the filename where the CSV will be stored locally — see the CSV [file documentation above]({{< relref "#creating-csv-files-for-contacts-reports" >}}) for the notation. The value of each key must be the ID of the corresponding file in Google Drive — the ID can be obtained from the URL eg `https://docs.google.com/spreadsheets/d/{FILE_ID}/edit`. +The file `csvs-on-google-drive.json` in your project's home directory will consist of a key value pair for each CSV file. The keys must be the filename where the CSV will be stored locally — see the CSV [file documentation above](/#creating-csv-files-for-contacts-reports) for the notation. The value of each key must be the ID of the corresponding file in Google Drive — the ID can be obtained from the URL eg `https://docs.google.com/spreadsheets/d/{FILE_ID}/edit`. ```json { diff --git a/content/en/community/contributing/code/troubleshooting/obtaining-logs.md b/content/en/community/contributing/code/troubleshooting/obtaining-logs.md index 67bcf75230..cde6cb128d 100644 --- a/content/en/community/contributing/code/troubleshooting/obtaining-logs.md +++ b/content/en/community/contributing/code/troubleshooting/obtaining-logs.md @@ -84,4 +84,4 @@ adb logcat | grep MedicMobile > phone.log ## On the server -Some unexpected errors are caught and stored in `feedback` docs and stored on the phone and later synced to CouchDB on the server. To access these, look for docs in the `medic-user-{username}-meta` or `medic-users-meta` databases. This is particularly useful to debug issues where you do not have physical access to the device. More information is available under [Managing Databases]({{< relref "technical-overview/data" >}}). +Some unexpected errors are caught and stored in `feedback` docs and stored on the phone and later synced to CouchDB on the server. To access these, look for docs in the `medic-user-{username}-meta` or `medic-users-meta` databases. This is particularly useful to debug issues where you do not have physical access to the device. More information is available under [Managing Databases](/technical-overview/data). diff --git a/content/en/community/contributing/code/troubleshooting/replicating-production-data-locally.md b/content/en/community/contributing/code/troubleshooting/replicating-production-data-locally.md index f1edeaf0ed..226b357a4a 100644 --- a/content/en/community/contributing/code/troubleshooting/replicating-production-data-locally.md +++ b/content/en/community/contributing/code/troubleshooting/replicating-production-data-locally.md @@ -66,7 +66,7 @@ A local development environment will be useful to you if: ### Option 1, local development environment -If you don't already have a local dev env, follow the instructions on the [development setup instructions]({{< relref "community/contributing/code/core/dev-environment" >}}). +If you don't already have a local dev env, follow the instructions on the [development setup instructions](/community/contributing/code/core/dev-environment). Then you need to: diff --git a/content/en/community/contributing/disclosing-vulnerabilities.md b/content/en/community/contributing/disclosing-vulnerabilities.md index be7427e4b0..7ba3e3c5f8 100644 --- a/content/en/community/contributing/disclosing-vulnerabilities.md +++ b/content/en/community/contributing/disclosing-vulnerabilities.md @@ -34,7 +34,7 @@ If you follow these guidelines when reporting an issue to us, we commit to: ## In Scope -A local CHT instance is included in the scope. Follow the [manual instructions]({{< relref "/hosting/cht/app-developer" >}}) to set up a CHT instance. +A local CHT instance is included in the scope. Follow the [manual instructions](//hosting/cht/app-developer) to set up a CHT instance. ## Out of scope diff --git a/content/en/hosting/_index.md b/content/en/hosting/_index.md index d7aff0ed2d..f9a0780d0f 100644 --- a/content/en/hosting/_index.md +++ b/content/en/hosting/_index.md @@ -10,9 +10,9 @@ aliases: This section has instructions on how to host the CHT Core starting with the most basic Application Development setup on your laptop for just one developer all the way up to large deployments which include multi-node CouchDB cluster hosted in a Cloud based deployment. -New developers to the CHT should start with the [Application Developer Hosting]({{< relref "/hosting/cht/app-developer" >}}). +New developers to the CHT should start with the [Application Developer Hosting](//hosting/cht/app-developer). -System administrators looking to deploy CHT into production should understand [the requirements to host the CHT]({{< relref "/hosting/cht/requirements/" >}}) first, then read the [Docker or Kubernetes]({{< relref "/hosting/cht/kubernetes-vs-docker/" >}}) to select a style of hosting that best fits them. +System administrators looking to deploy CHT into production should understand [the requirements to host the CHT](//hosting/cht/requirements/) first, then read the [Docker or Kubernetes](//hosting/cht/kubernetes-vs-docker/) to select a style of hosting that best fits them. {{< cards >}} {{< card link="cht/" title="CHT Core" icon="template" subtitle="Guides for hosting CHT applications" >}} diff --git a/content/en/hosting/analytics/_index.md b/content/en/hosting/analytics/_index.md index b704ce70b4..d0f02fdb13 100644 --- a/content/en/hosting/analytics/_index.md +++ b/content/en/hosting/analytics/_index.md @@ -16,6 +16,6 @@ aliases: Most CHT deployments require some sort of analytics so that stakeholders can make data driven decisions. CouchDB, which is the database used by the CHT, is not designed for analytics. It is a document database, which means that it is optimized for storing and retrieving documents, and not for aggregating data. For example, if you wanted to know how many patients were registered in a particular area, you would have to query the database for all the patients in that area, and then count them. This is not a very efficient process. It is much more efficient to store the number of patients in a particular area in a separate database, and update that number whenever a patient is registered or unregistered. This is what CHT Sync is designed to do. -[CHT Sync]({{< relref "technical-overview/architecture/cht-sync" >}}) is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It has been designed to work in both local development environments for testing models or workflows, and in production environments. It can be deployed using [Docker or Kubernetes]({{< relref "/hosting/cht/kubernetes-vs-docker" >}}). It is supported on CHT 3.12 and later, including CHT 4.x. By using CHT Sync, a CHT deployment can easily get analytics by using a [data visualization tool]({{< relref "/hosting/analytics/dashboards" >}}), such as [Superset](https://superset.apache.org/). CHT Sync is open-source and has no licensing fees. +[CHT Sync](/technical-overview/architecture/cht-sync) is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It has been designed to work in both local development environments for testing models or workflows, and in production environments. It can be deployed using [Docker or Kubernetes](//hosting/cht/kubernetes-vs-docker). It is supported on CHT 3.12 and later, including CHT 4.x. By using CHT Sync, a CHT deployment can easily get analytics by using a [data visualization tool](//hosting/analytics/dashboards), such as [Superset](https://superset.apache.org/). CHT Sync is open-source and has no licensing fees. {{< subpages >}} diff --git a/content/en/hosting/analytics/building-dbt-models.md b/content/en/hosting/analytics/building-dbt-models.md index 4cf386d250..78f4133a95 100644 --- a/content/en/hosting/analytics/building-dbt-models.md +++ b/content/en/hosting/analytics/building-dbt-models.md @@ -16,7 +16,7 @@ aliases: Guide for building dbt models for CHT applications {{< /hextra/hero-subtitle >}} -[CHT Sync]({{< relref "technical-overview/architecture/cht-sync" >}}) copies data from CouchDB to a relational database. It initially stores the document data from CouchDB in a `jsonb` column in a single PostgreSQL table. This is not possible to query for analytics, so it uses [dbt](https://www.getdbt.com/) to convert the document data to a relational database format. +[CHT Sync](/technical-overview/architecture/cht-sync) copies data from CouchDB to a relational database. It initially stores the document data from CouchDB in a `jsonb` column in a single PostgreSQL table. This is not possible to query for analytics, so it uses [dbt](https://www.getdbt.com/) to convert the document data to a relational database format. The [cht-pipeline repository](https://github.com/medic/cht-pipeline) defines a dbt project, which contains model files for the data schema described in the [database schema conventions]({{< ref "technical-overview/data/db-schema" >}}). Forms may be specific to each CHT application; additional models will need to be developed to analyze data from responses to these custom forms. @@ -25,7 +25,7 @@ If using the [configurable contact hierarchy]({{< ref "building/reference/app-se ## Prerequisites -- An existing install of CHT Sync via [Docker]({{< relref "/hosting/analytics/setup-docker-compose" >}}) or [Kubernetes]({{< relref "/hosting/analytics/setup-kubernetes" >}}) +- An existing install of CHT Sync via [Docker](//hosting/analytics/setup-docker-compose) or [Kubernetes](//hosting/analytics/setup-kubernetes) - [cht-pipeline](https://github.com/medic/cht-pipeline) GitHub repository (can be cloned via `git clone https://github.com/medic/cht-pipeline`). ## Setup @@ -39,14 +39,14 @@ packages: ``` To avoid breaking changes in downstream models, include `revision` in the dependency, which should be a version tag for `cht-pipeline`. -In the CHT Sync config, set the URL of the dbt GitHub repository to the `CHT_PIPELINE_BRANCH_URL` [environment variable]({{< relref "/hosting/analytics/environment-variables" >}}), either in `.env` if using Docker compose, or in `values.yaml` if using Kubernetes. +In the CHT Sync config, set the URL of the dbt GitHub repository to the `CHT_PIPELINE_BRANCH_URL` [environment variable](//hosting/analytics/environment-variables), either in `.env` if using Docker compose, or in `values.yaml` if using Kubernetes. > [!IMPORTANT] > If `CHT_PIPELINE_BRANCH_URL` is pointing to a private GitHub repository, you'll need an access token in the URL. Assuming your repository is `medic/cht-pipeline`, you would replace `` with an access token: `https://@github.com/medic/cht-pipeline.git#main`. See [GitHub's instructions](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) on how to generate a token. If you create a fine-grained access token you need to provide read and write access to the [contents](https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28#repository-permissions-for-contents) of the repository. ### Local development -When creating/modifying models, you can use the Docker [local profile]({{< relref "/hosting/analytics/setup-docker-compose#local" >}}) to run a local test instance of CHT Sync that can reference your model configuration directly on your local machine (without needing to commit/push the changes remotely). +When creating/modifying models, you can use the Docker [local profile](//hosting/analytics/setup-docker-compose#local) to run a local test instance of CHT Sync that can reference your model configuration directly on your local machine (without needing to commit/push the changes remotely). ### Deploying models @@ -395,7 +395,7 @@ Examples of changes that are not considered breaking: - adding tests ## Database disk space requirements -The disk space required for the database depends on a few things including the size the of CouchDB databases being replicated, and the [models]({{< relref "/hosting/analytics/building-dbt-models" >}}) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to Postgres and then run the following command to see disk usage: +The disk space required for the database depends on a few things including the size the of CouchDB databases being replicated, and the [models](//hosting/analytics/building-dbt-models) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to Postgres and then run the following command to see disk usage: ```shell SELECT pg_size_pretty(pg_database_size('your_database_name')); ``` @@ -410,7 +410,7 @@ To get the percentage of documents that have synced you can run the following qu SELECT (COUNT(*) * 100 / (COUNT(*) + (SELECT SUM(pending) FROM v1.couchdb_progress))) AS sync_percentage FROM v1.couchdb; ``` -This query selects the total number of documents that have been synced to the `v1.couchdb` table and divides it by the total number of documents that have been synced and the number of documents that are pending to be synced. This will give you the percentage of documents that have been synced. Note that the schema and table name could differ according to the [environment variables]({{< relref "/hosting/analytics/environment-variables" >}}) you set so update them accordingly. Run this query periodically to monitor the progress of the sync and stop the sync process once you get to the desired percentage. It's okay if it is not exactly 10% as long as it is close enough to give you an idea of the disk space required. +This query selects the total number of documents that have been synced to the `v1.couchdb` table and divides it by the total number of documents that have been synced and the number of documents that are pending to be synced. This will give you the percentage of documents that have been synced. Note that the schema and table name could differ according to the [environment variables](//hosting/analytics/environment-variables) you set so update them accordingly. Run this query periodically to monitor the progress of the sync and stop the sync process once you get to the desired percentage. It's okay if it is not exactly 10% as long as it is close enough to give you an idea of the disk space required. You can then multiply this figure by 10 to get an estimate of the disk space required for the full dataset and then add some extra space for indexes and other overhead as well as future growth. diff --git a/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md b/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md index f9414d5da4..25ad9365ee 100644 --- a/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md +++ b/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md @@ -12,22 +12,22 @@ aliases: - /building/guides/data/analytics/couch2pg-to-cht-sync-migration --- -This page outlines guidelines for migrating from [couch2pg](https://github.com/medic/cht-couch2pg) to the data pipeline based on [CHT Sync](https://github.com/medic/cht-sync). One of the main changes in this flow is separating the syncing process from the data transformation, with dbt now handling the latter in [cht-pipeline](https://github.com/medic/cht-pipeline/). This migration requires dbt models in the cht-pipeline repository instead of SQL views and tables. One thing to note is that the schema for CHT Sync differs from cht-couch2pg, so dbt models will not directly replace the SQL views and tables. For instructions on how to get started with dbt models, refer to the [dbt models guide]({{< relref "/hosting/analytics/testing-dbt-models" >}}). +This page outlines guidelines for migrating from [couch2pg](https://github.com/medic/cht-couch2pg) to the data pipeline based on [CHT Sync](https://github.com/medic/cht-sync). One of the main changes in this flow is separating the syncing process from the data transformation, with dbt now handling the latter in [cht-pipeline](https://github.com/medic/cht-pipeline/). This migration requires dbt models in the cht-pipeline repository instead of SQL views and tables. One thing to note is that the schema for CHT Sync differs from cht-couch2pg, so dbt models will not directly replace the SQL views and tables. For instructions on how to get started with dbt models, refer to the [dbt models guide](//hosting/analytics/testing-dbt-models). ## Key Considerations -- **Kubernetes vs Docker Compose**: CHT Sync provides configurations to support deployment to test and production environments with Docker Compose or Kubernetes. You can read more about the CHT hosting options in the [dedicated page]({{< relref "/hosting/cht/kubernetes-vs-docker" >}}). -- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources]({{< relref "/hosting/analytics/building-dbt-models#database-disk-space-requirements" >}}) are sufficient to handle the load. +- **Kubernetes vs Docker Compose**: CHT Sync provides configurations to support deployment to test and production environments with Docker Compose or Kubernetes. You can read more about the CHT hosting options in the [dedicated page](//hosting/cht/kubernetes-vs-docker). +- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources](//hosting/analytics/building-dbt-models#database-disk-space-requirements) are sufficient to handle the load. - **dbt modelling**: Avoid the temptation to model new dbt models after existing SQL views and tables. Instead, take the opportunity to re-evaluate the data needs and design new models that are more efficient and effective. Think of what data needs to be shown and how it should be shown in data visualization tools and use that to guide the design of the new models. -- **Testing**: After migrating, thoroughly test the new dbt models to ensure that they work as expected. Refer to the [testing dbt models guide]({{< relref "/hosting/analytics/building-dbt-models" >}}) for guidelines on testing. +- **Testing**: After migrating, thoroughly test the new dbt models to ensure that they work as expected. Refer to the [testing dbt models guide](//hosting/analytics/building-dbt-models) for guidelines on testing. - **Feedback**: Provide any feedback and create issues for errors or bugs encountered in the [cht-sync](https://github.com/medic/cht-sync) and [cht-pipeline](https://github.com/medic/cht-pipeline/) repositories to improve the tools. ## Migration Steps 1. **Plan the migration**: Determine the scope of the migration, including the data sources, the data models, and the data transformations. Identify the existing SQL views, tables, and dashboards and assess what data you want to visualize. -1. **Set up CHT Sync**: Follow the instructions to setup CHT Sync with [Docker Compose]({{< relref "/hosting/analytics/setup-docker-compose" >}}) or [Kubernetes]({{< relref "/hosting/analytics/setup-kubernetes" >}}) -1. **Build dbt models**: Use the [dedicated guidelines]({{< relref "/hosting/analytics/building-dbt-models" >}}) to build dbt models for the data you want to visualize. +1. **Set up CHT Sync**: Follow the instructions to setup CHT Sync with [Docker Compose](//hosting/analytics/setup-docker-compose) or [Kubernetes](//hosting/analytics/setup-kubernetes) +1. **Build dbt models**: Use the [dedicated guidelines](//hosting/analytics/building-dbt-models) to build dbt models for the data you want to visualize. 1. **Deploy CHT Sync**: Once the dbt models are tested locally or in a test environment and working as expected, deploy CHT Sync in a production environment. It is recommended that CHT Sync be run in parallel with couch2pg during the migration process. This minimises disruption to users of the existing dashboards because they can continue to use the existing data while the new pipeline is being set up. It also makes it easier to compare the data from couch2pg when testing the new pipeline. 1. **Create replica dashboards**: In the data visualization tool of your choice, create replica dashboards of your current setup and compare the data from the old and new pipelines. 1. **Test and adjust the dbt models**: Test the dbt models to ensure they are working as expected and that the replica and initial dashboards match. Adjust the models to ensure they are accurate. -1. **Optimize**: Once the dbt models are working as expected and the dashboards display the expected data, optimize the models to improve performance. This may involve restructuring the models, adding indexes, or making other adjustments to improve the speed and efficiency of the models. Having a look at the [dbt models guide]({{< relref "/hosting/analytics/building-dbt-models" >}}) will help you understand how to optimize the models. -1. **Set up monitoring and alerting**: [Set up CHT Watchdog]({{< relref "/hosting/monitoring/setup" >}}) to monitor the running of CHT Sync and set up alerts for any failures. +1. **Optimize**: Once the dbt models are working as expected and the dashboards display the expected data, optimize the models to improve performance. This may involve restructuring the models, adding indexes, or making other adjustments to improve the speed and efficiency of the models. Having a look at the [dbt models guide](//hosting/analytics/building-dbt-models) will help you understand how to optimize the models. +1. **Set up monitoring and alerting**: [Set up CHT Watchdog](//hosting/monitoring/setup) to monitor the running of CHT Sync and set up alerts for any failures. 1. **Remove couch2pg and the duplicate database**: Once the new pipeline runs as expected, you can remove couch2pg and the duplicate database. Ensure that all data is being synced correctly, that the dbt models are working as expected, and that the dashboards display the expected data before switching them off and removing couch2pg. diff --git a/content/en/hosting/analytics/dashboards.md b/content/en/hosting/analytics/dashboards.md index 1e63e53201..cf12e8c530 100644 --- a/content/en/hosting/analytics/dashboards.md +++ b/content/en/hosting/analytics/dashboards.md @@ -10,7 +10,7 @@ relatedContent: > --- {{< callout >}} - These instructions assume you are running CHT Sync, CHT Core and PostgreSQL either with [Kubernetes]({{< relref "/hosting/analytics/setup-kubernetes" >}}) or [Docker]({{< relref "/hosting/analytics/setup-docker-compose" >}}). + These instructions assume you are running CHT Sync, CHT Core and PostgreSQL either with [Kubernetes](//hosting/analytics/setup-kubernetes) or [Docker](//hosting/analytics/setup-docker-compose). {{< /callout >}} ## Superset diff --git a/content/en/hosting/analytics/environment-variables.md b/content/en/hosting/analytics/environment-variables.md index ca5972b481..18f811b507 100644 --- a/content/en/hosting/analytics/environment-variables.md +++ b/content/en/hosting/analytics/environment-variables.md @@ -32,8 +32,8 @@ There are three groups of environment variables. One for Postgres, one for Couch | `COUCHDB_HOST` | `couchdb` | Host of the CouchDB instance | | `COUCHDB_PORT` | `5984` | Port of the CouchDB instance | | `COUCHDB_SECURE` | `false` | Does the connection to CouchDB use HTTPS? | -| `DBT_THREAD_COUNT` | 1 | [Number of threads]({{< relref "/hosting/analytics/tuning-dbt#threads" >}}) per DBT process | -| `DBT_BATCH_SIZE` | 0 | [Batch size]({{< relref "/hosting/analytics/tuning-dbt#batching" >}}) for batched incremental runs | +| `DBT_THREAD_COUNT` | 1 | [Number of threads](//hosting/analytics/tuning-dbt#threads) per DBT process | +| `DBT_BATCH_SIZE` | 0 | [Batch size](//hosting/analytics/tuning-dbt#batching) for batched incremental runs | | `DBT_LOCAL_PATH` | | When running DBT locally for development, the path to the models directory on the host | -| `DBT_SELECTOR` | '' | If using separate DBT processes, the [select condition]({{< relref "/hosting/analytics/tuning-dbt#multiple-dbt-containers" >}}) to select a subset of the models for a single dbt process. | +| `DBT_SELECTOR` | '' | If using separate DBT processes, the [select condition](//hosting/analytics/tuning-dbt#multiple-dbt-containers) to select a subset of the models for a single dbt process. | diff --git a/content/en/hosting/analytics/setup-docker-compose.md b/content/en/hosting/analytics/setup-docker-compose.md index c8e51259d4..9fd81e9c7d 100644 --- a/content/en/hosting/analytics/setup-docker-compose.md +++ b/content/en/hosting/analytics/setup-docker-compose.md @@ -12,20 +12,20 @@ aliases: - /building/guides/data/analytics/setup --- -This guide will walk you through setting up a deployment of CHT Sync with the CHT using Docker. This path is recommended if you host the [CHT with Docker]({{< relref "/hosting/cht/docker" >}}). +This guide will walk you through setting up a deployment of CHT Sync with the CHT using Docker. This path is recommended if you host the [CHT with Docker](//hosting/cht/docker). ## Prerequisites - [Current version](https://docs.docker.com/engine/install/) of `docker` or current version of [Docker Desktop](https://www.docker.com/products/docker-desktop/) both of which include `docker compose`. Note that the older `docker-compose` is [no longer supported](https://www.docker.com/blog/announcing-compose-v2-general-availability/). - [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - [cht-sync](https://github.com/medic/cht-sync) GitHub repository (can be cloned via `git clone https://github.com/medic/cht-sync`). -- [A dbt project]({{< relref "/hosting/analytics/building-dbt-models" >}}). +- [A dbt project](//hosting/analytics/building-dbt-models). ## Setup -In the `cht-sync` folder, copy the values from the `env.template` file to a `.env` file. For more information, see the references on the [Environment variables page]({{< relref "/hosting/analytics/environment-variables" >}}). +In the `cht-sync` folder, copy the values from the `env.template` file to a `.env` file. For more information, see the references on the [Environment variables page](//hosting/analytics/environment-variables). -Configure the `COUCHDB_*` environment variables to connect to your CouchDB instance. For production CHT Core deployments, the port will most likely need to be set to `443` like this: `COUCHDB_PORT=443`. This is because CHT Core uses an `nginx` [reverse proxy]({{< relref "technical-overview/architecture#overview" >}}) on port `443`, instead of the default `5984` port used in a stand-alone CouchDB instance which the `env.template` [has]({{< relref "/hosting/analytics/environment-variables" >}}). +Configure the `COUCHDB_*` environment variables to connect to your CouchDB instance. For production CHT Core deployments, the port will most likely need to be set to `443` like this: `COUCHDB_PORT=443`. This is because CHT Core uses an `nginx` [reverse proxy](/technical-overview/architecture#overview) on port `443`, instead of the default `5984` port used in a stand-alone CouchDB instance which the `env.template` [has](//hosting/analytics/environment-variables). > [!IMPORTANT] > The first time you run the commands from any of the sections below it will need to download many Docker images and will take a while. You'll know it's done when you see `#8 DONE 0.0s` and you are returned to the command line. Be patient! @@ -43,7 +43,7 @@ The following profiles are available: This setup involves starting couch2pg, PostgreSQL, pgAdmin and dbt. It assumes you have a CouchDB instance running, and you updated the `.env` CouchDB variables accordingly. -The dbt container needs a project to run. To develop and test models locally, [set up a dbt project]({{< relref "/hosting/analytics/building-dbt-models#setup" >}}) and set the path to the project to the `DBT_LOCAL_PATH` [environment variable]({{< relref "/hosting/analytics/environment-variables" >}}) in `.env`. You must set this to a valid directory where you have your CHT Pipeline models. You can not use `--local` profile without setting this. +The dbt container needs a project to run. To develop and test models locally, [set up a dbt project](//hosting/analytics/building-dbt-models#setup) and set the path to the project to the `DBT_LOCAL_PATH` [environment variable](//hosting/analytics/environment-variables) in `.env`. You must set this to a valid directory where you have your CHT Pipeline models. You can not use `--local` profile without setting this. When running, the dbt container then will use the local models in the path specified in `DBT_LOCAL_PATH` with out needing to query a remote git repository. @@ -68,7 +68,7 @@ The dbt container will run the models in the path specified in `DBT_LOCAL_PATH`. #### Production -This setup involves starting couch2pg and one dbt container. It assumes you have an external CouchDB instance and Postgres DB. The credentials and settings for these databases are configured in [.env]({{< relref "/hosting/analytics/environment-variables" >}}). +This setup involves starting couch2pg and one dbt container. It assumes you have an external CouchDB instance and Postgres DB. The credentials and settings for these databases are configured in [.env](//hosting/analytics/environment-variables). Run the Docker containers with profile `production` and wait for every container to be up and running: ```sh @@ -79,7 +79,7 @@ You can verify this command worked by running `docker ps`. It should show three ### Tuning dbt -In production setups with large tables, it can be helpful to [tune how dbt runs]({{< relref "/hosting/analytics/tuning-dbt" >}}). +In production setups with large tables, it can be helpful to [tune how dbt runs](//hosting/analytics/tuning-dbt). To use threads or batching, set the corresponding environment variables in `.env`. ```conf @@ -178,4 +178,4 @@ To add these columns log in to the database and run this sql. In V2, the commands for running CHT sync have changed; a profile is required as described above. When testinging locally and using the `local` profile, the environment variable `DBT_LOCAL_PATH` must be set. -V2 adds new features for [tuning dbt]({{< relref "/hosting/analytics/tuning-dbt" >}}); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables]({{< relref "/hosting/analytics/environment-variables" >}}) in `.env` as described above. +V2 adds new features for [tuning dbt](//hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](//hosting/analytics/environment-variables) in `.env` as described above. diff --git a/content/en/hosting/analytics/setup-kubernetes.md b/content/en/hosting/analytics/setup-kubernetes.md index 80e2d7e3f1..7bd6621321 100644 --- a/content/en/hosting/analytics/setup-kubernetes.md +++ b/content/en/hosting/analytics/setup-kubernetes.md @@ -12,7 +12,7 @@ aliases: - /building/guides/data/analytics/production --- -This guide will walk you through setting up a deployment of CHT Sync with the CHT using Kubernetes. This path is recommended if you already have a Kubernetes cluster [hosting the CHT]({{< relref "/hosting/cht/kubernetes" >}}). +This guide will walk you through setting up a deployment of CHT Sync with the CHT using Kubernetes. This path is recommended if you already have a Kubernetes cluster [hosting the CHT](//hosting/cht/kubernetes). ## Prerequisites @@ -87,13 +87,13 @@ If an instance has a different port, user or different CouchDB databases to be s password: "password3" ``` -Set the [cht-pipeline branch URL]({{< relref "/hosting/analytics/building-dbt-models#setup" >}}) in the `values.yaml` file. +Set the [cht-pipeline branch URL](//hosting/analytics/building-dbt-models#setup) in the `values.yaml` file. ```yaml cht_pipeline_branch_url: "https://github.com/medic/cht-pipeline.git#main" ``` -(Optional) You can also configure a Metrics Exporter. If enabled, this will create a sql exporter that queries the database for couch2pg status, number of changes pending, and current sequence and exposes these metrics in Prometheus format at a service with name `metrics` at port 9399, for use with [CHT Watchdog]({{< relref "/hosting/monitoring/setup" >}}) or any other monitoring service. +(Optional) You can also configure a Metrics Exporter. If enabled, this will create a sql exporter that queries the database for couch2pg status, number of changes pending, and current sequence and exposes these metrics in Prometheus format at a service with name `metrics` at port 9399, for use with [CHT Watchdog](//hosting/monitoring/setup) or any other monitoring service. An HTTP ingress needs to be created to allow access from outside the cluster. @@ -126,7 +126,7 @@ kubectl logs -f cht-sync- ### Tuning dbt -In production setups with large tables, it can be helpful to [tune how dbt runs]({{< relref "/hosting/analytics/tuning-dbt" >}}). +In production setups with large tables, it can be helpful to [tune how dbt runs](//hosting/analytics/tuning-dbt). To use threads or batching, set the corresponding values in the `values.yaml` file. ```yaml @@ -168,4 +168,4 @@ To add these columns log in to the database and run this sql. CREATE INDEX IF NOT EXISTS source ON couchdb(source); ``` -V2 adds new features for [tuning dbt]({{< relref "/hosting/analytics/tuning-dbt" >}}); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables]({{< relref "/hosting/analytics/environment-variables" >}}) in `values.yml` as described above. +V2 adds new features for [tuning dbt](//hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](//hosting/analytics/environment-variables) in `values.yml` as described above. diff --git a/content/en/hosting/analytics/tuning-dbt.md b/content/en/hosting/analytics/tuning-dbt.md index be8a775741..49d4a15c34 100644 --- a/content/en/hosting/analytics/tuning-dbt.md +++ b/content/en/hosting/analytics/tuning-dbt.md @@ -39,10 +39,10 @@ Each dbt container is passed an environment variable `DBT_SELECTOR` that is used One dbt container should be set up to run the base models. This can be done by using the selector `package:cht_pipeline_base` or, to separate telemetry models from base models, use `tag:base` and `tag:users`. -To run custom models in separate containers, either use a package select with your dbt package name (`package:[YOUR_PACKAGE_NAME]`), or for more fine-grained control, add [tags]({{< relref "/hosting/analytics/tuning-dbt#dbt-tags" >}}) to your models and use tag selectors (`tag:[YOUR_TAG]`). +To run custom models in separate containers, either use a package select with your dbt package name (`package:[YOUR_PACKAGE_NAME]`), or for more fine-grained control, add [tags](//hosting/analytics/tuning-dbt#dbt-tags) to your models and use tag selectors (`tag:[YOUR_TAG]`). Although it is possible to use any condition, using tags is the simplest way to separate models. -How to configure the different dbt containers to use these selectors depends on whether CHT Sync is running in [docker-compose]({{< relref "/hosting/analytics/setup-docker-compose#tuning-dbt" >}}) or [kubernetes]({{< relref "/hosting/analytics/setup-kubernetes#tuning-dbt" >}}). +How to configure the different dbt containers to use these selectors depends on whether CHT Sync is running in [docker-compose](//hosting/analytics/setup-docker-compose#tuning-dbt) or [kubernetes](//hosting/analytics/setup-kubernetes#tuning-dbt). In Kubernetes, add the selectors to the `values.yaml` file as a list called `dbt_selectors` ```yaml diff --git a/content/en/hosting/cht/_index.md b/content/en/hosting/cht/_index.md index e198b8a31d..d518496778 100644 --- a/content/en/hosting/cht/_index.md +++ b/content/en/hosting/cht/_index.md @@ -11,11 +11,11 @@ aliases: --- > [!TIP] -> To get an overview on how these hosting solutions use `docker` and other key CHT concepts, be sure to read the [guide on a Local Setup]({{< relref "building/local-setup" >}}). +> To get an overview on how these hosting solutions use `docker` and other key CHT concepts, be sure to read the [guide on a Local Setup](/building/local-setup). -Before beginning any of these guides, be sure to meet all of the [CHT hosting requirements]({{< relref "/hosting/cht/requirements" >}}) first. For example, [backups](/hosting/cht/docker/backups) are required for any successful CHT deployment. +Before beginning any of these guides, be sure to meet all of the [CHT hosting requirements](//hosting/cht/requirements) first. For example, [backups](/hosting/cht/docker/backups) are required for any successful CHT deployment. -To host a production instance of CHT, use the [Production Hosting in CHT]({{< relref "/hosting/cht/docker" >}}) guide. To do app development, see our [App Developer]({{< relref "/hosting/cht/app-developer" >}}) hosting guide. +To host a production instance of CHT, use the [Production Hosting in CHT](//hosting/cht/docker) guide. To do app development, see our [App Developer](//hosting/cht/app-developer) hosting guide. {{< cards >}} {{< card link="considerations" title="Considerations" subtitle="Considerations when hosting the CHT" icon="book-open" >}} diff --git a/content/en/hosting/cht/app-developer.md b/content/en/hosting/cht/app-developer.md index 160f1bf032..5b70f6b892 100644 --- a/content/en/hosting/cht/app-developer.md +++ b/content/en/hosting/cht/app-developer.md @@ -12,9 +12,9 @@ aliases: --- {{< callout >}} -This guide assumes you are a CHT app developer wanting to either run concurrent instances of the CHT, or easily be able to switch between different instances without losing any data while doing so. To do development on the CHT Core Framework itself, see the [development guide]({{< relref "community/contributing/code/core/dev-environment" >}}). +This guide assumes you are a CHT app developer wanting to either run concurrent instances of the CHT, or easily be able to switch between different instances without losing any data while doing so. To do development on the CHT Core Framework itself, see the [development guide](/community/contributing/code/core/dev-environment). -To deploy the CHT in production, see see the [production]({{< relref "/hosting/cht/docker" >}}) documentation. +To deploy the CHT in production, see see the [production](//hosting/cht/docker) documentation. {{< /callout >}} ## Getting started @@ -39,7 +39,7 @@ This script brings a lot of benefits with it: ### Installing To get started using it: -1. Meet all [CHT hosting requirements]({{< relref "/hosting/cht/requirements" >}}) +1. Meet all [CHT hosting requirements](//hosting/cht/requirements) 2. Clone the [CHT Core](https://github.com/medic/cht-core/) repo 3. When you want to check for updates, just run `git pull origin` in the `cht-core` directory. @@ -196,7 +196,7 @@ Here is a video of the helper being run on 1 Dec 2022. The video references `laz ## Manual `docker compose` method -This process achieves the same result as Docker Helper, but is a more manual process. Be sure the [CHT hosting requirements]({{< relref "/hosting/cht/requirements" >}}) are all met first. +This process achieves the same result as Docker Helper, but is a more manual process. Be sure the [CHT hosting requirements](//hosting/cht/requirements) are all met first. To avoid conflicts, ensure that all other CHT 4.x instances are stopped. To stop ALL containers, you can use diff --git a/content/en/hosting/cht/considerations.md b/content/en/hosting/cht/considerations.md index f2e4522dda..ff91ad0284 100644 --- a/content/en/hosting/cht/considerations.md +++ b/content/en/hosting/cht/considerations.md @@ -10,12 +10,12 @@ aliases: --- Some important questions to consider when setting up hosting for the CHT: -* **Alerting** - How will alerts be sent in the case of downtime or degraded service? While [Watchdog]({{< relref "/hosting/monitoring/introduction" >}}) can be set up to monitor CHT Core instances - which monitoring system will be used to alert on OS level warnings? +* **Alerting** - How will alerts be sent in the case of downtime or degraded service? While [Watchdog](//hosting/monitoring/introduction) can be set up to monitor CHT Core instances - which monitoring system will be used to alert on OS level warnings? * **Power failures and unplanned restarts** - Will the server cleanly restart such that the CHT resumes service correctly? -* **Backups** - What happens to the CHT data if there's a hard drive failure? Are there provisions for a [3-2-1 backup strategy](https://en.wikipedia.org/wiki/Backup#Storage)? See the [backup docs]({{< relref "/hosting/cht/docker/backups" >}}) for more information. +* **Backups** - What happens to the CHT data if there's a hard drive failure? Are there provisions for a [3-2-1 backup strategy](https://en.wikipedia.org/wiki/Backup#Storage)? See the [backup docs](//hosting/cht/docker/backups) for more information. * **Disaster Recovery** - What happens if there is a flood at the facility and on-site active and backup data are destroyed? * **Scale** - What happens when the hardware deployed needs to be upgraded to increase capacity? * **Updates** - CHT Core updates happen many times throughout the year - do you have a maintenance schedule for these and staff who are trained to do the upgrade? * **Renewals** - Services such as TLS certificates and domains name registration expire periodically and will make the server inaccessible - do you have a schedule for monitoring and renewing these in a timely manner? -* **Security** - While the TLS certificate will protect data on the Internet, is the server hard drive encrypted in the event of property theft? Is there a sufficient policy in place when generating and handling passwords for CHWs? Have you considered [Token Login]({{< relref "building/login#magic-links-for-logging-in-token-login" >}}) to further reduce risk? +* **Security** - While the TLS certificate will protect data on the Internet, is the server hard drive encrypted in the event of property theft? Is there a sufficient policy in place when generating and handling passwords for CHWs? Have you considered [Token Login](/building/login#magic-links-for-logging-in-token-login) to further reduce risk? * **Privacy** - The CHT inherently carries sensitive patient medical information in the database. Are there sufficient measures in place to protect this sensitive data? diff --git a/content/en/hosting/cht/docker/_index.md b/content/en/hosting/cht/docker/_index.md index 1e526ad020..8b416f0dcd 100644 --- a/content/en/hosting/cht/docker/_index.md +++ b/content/en/hosting/cht/docker/_index.md @@ -8,7 +8,7 @@ aliases: --- {{< callout >}} -Read the [Docker vs Kubernetes]({{< relref "/hosting/cht/kubernetes-vs-docker/" >}}) documentation to select a style of hosting that best fits your CHT deployment. +Read the [Docker vs Kubernetes](//hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. {{< /callout >}} {{< cards >}} diff --git a/content/en/hosting/cht/docker/adding-tls-certificates.md b/content/en/hosting/cht/docker/adding-tls-certificates.md index 6100f2dd2c..1fa9eb6f22 100644 --- a/content/en/hosting/cht/docker/adding-tls-certificates.md +++ b/content/en/hosting/cht/docker/adding-tls-certificates.md @@ -13,7 +13,7 @@ aliases: By default, CHT will create a self-signed certificate for every deployment. These instructions are for changing to either a pre-existing certificate or automatically creating and renewing a [Certbot](https://certbot.eff.org/) based certificate using [ACME](https://acmeclients.com/), like [Let's Encrypt](https://letsencrypt.org/). -This guide assumes you've already met the [hosting requirements]({{< relref "/hosting/cht/requirements" >}}), specifically around Docker being installed. +This guide assumes you've already met the [hosting requirements](//hosting/cht/requirements), specifically around Docker being installed. ## Pre-existing certificate diff --git a/content/en/hosting/cht/docker/backups.md b/content/en/hosting/cht/docker/backups.md index f97a5ba8e0..840b79ea17 100644 --- a/content/en/hosting/cht/docker/backups.md +++ b/content/en/hosting/cht/docker/backups.md @@ -35,7 +35,7 @@ Therefore, you do **not** need to back up the docker images for: ## Assumptions -This guide assumes you have an Ubuntu server running CHT 4.x in Docker as described in our [Self Hosting in CHT 4.x - Single CouchDB Node]({{< relref "/hosting/cht/docker" >}}) guide. If you run `docker ps --format '{{.Names}}'` you should see something like this: +This guide assumes you have an Ubuntu server running CHT 4.x in Docker as described in our [Self Hosting in CHT 4.x - Single CouchDB Node](//hosting/cht/docker) guide. If you run `docker ps --format '{{.Names}}'` you should see something like this: ``` cht_nginx_1 @@ -76,7 +76,7 @@ Assuming your CouchDB is stored in `/home/ubuntu/cht/couchdb`, you should use th 1. While you don't need to stop CouchDB to back it up, ensure you follow best practices to back it up. See the [CouchDB site](https://docs.couchdb.org/en/stable/maintenance/backups.html) for more info. Note it is NOT recommended to use replication for backup. 2. It is strongly recommended you encrypt your backups given the sensitivity of the contents. Do this now before copying the backup files to their long term location. -3. Backup the CouchDB files using the [software specified above]({{< relref "#backup-software" >}}) +3. Backup the CouchDB files using the [software specified above](/#backup-software) ## Docker Compose files @@ -92,7 +92,7 @@ All compose files, and the corresponding `.env` file, are in these three locatio While all three of these are trivial to recreate by downloading them again, they may change over time so should be archived with your CouchDB data. Further, when there's been a critical failure of a production CHT instance, you want to be sure to make the restore process as speedy as possible. -As all of these files are only read when Docker first loads a service, you can simply copy them whenever you want without stopping any of the CHT services. They should be copied with the same frequency and put in the same location as the CouchDB data using the [backup software specified above]({{< relref "#backup-software" >}}). +As all of these files are only read when Docker first loads a service, you can simply copy them whenever you want without stopping any of the CHT services. They should be copied with the same frequency and put in the same location as the CouchDB data using the [backup software specified above](/#backup-software). ## TLS certificates @@ -108,7 +108,7 @@ Like the compose files, the TLS certificate files can easily be regenerated or r docker cp cht_nginx_1:/etc/nginx/private/key.pem . docker cp cht_nginx_1:/etc/nginx/private/cert.pem . ``` -2. Back the up to the same location and frequency as the CouchDB data using the [backup software specified above]({{< relref "#backup-software" >}}). +2. Back the up to the same location and frequency as the CouchDB data using the [backup software specified above](/#backup-software). ## Testing backups diff --git a/content/en/hosting/cht/docker/installation.md b/content/en/hosting/cht/docker/installation.md index ea151641be..7a99851d0e 100644 --- a/content/en/hosting/cht/docker/installation.md +++ b/content/en/hosting/cht/docker/installation.md @@ -17,7 +17,7 @@ aliases: ## Prerequisites -Be sure you have followed [the requirements document]({{< relref "/hosting/cht/requirements" >}}) including installing Docker. This guide assumes you're using the `ubuntu` user and that it [has `sudo-less` access to Docker](https://askubuntu.com/a/477554). +Be sure you have followed [the requirements document](//hosting/cht/requirements) including installing Docker. This guide assumes you're using the `ubuntu` user and that it [has `sudo-less` access to Docker](https://askubuntu.com/a/477554). ## Directory Structure @@ -89,7 +89,7 @@ Note that secure passwords and UUIDs were generated on the first four calls and ## Launch containers > [!IMPORTANT] -> This section has the first use of `docker compose`. If you get an error calling this, double check [hosting requirements]({{< relref "/hosting/cht/requirements" >}}). +> This section has the first use of `docker compose`. If you get an error calling this, double check [hosting requirements](//hosting/cht/requirements). To start your CHT instance, run the following @@ -138,7 +138,7 @@ grep COUCHDB_PASSWORD /home/ubuntu/cht/upgrade-service/.env | cut -d'=' -f2 ## TLS Certificates -See the [TLS Certificates page]({{< relref "/hosting/cht/docker/adding-tls-certificates" >}}) for how to import your certificates. +See the [TLS Certificates page](//hosting/cht/docker/adding-tls-certificates) for how to import your certificates. ## Upgrades diff --git a/content/en/hosting/cht/kubernetes-vs-docker.md b/content/en/hosting/cht/kubernetes-vs-docker.md index f60ad47c0b..e6516d82a4 100644 --- a/content/en/hosting/cht/kubernetes-vs-docker.md +++ b/content/en/hosting/cht/kubernetes-vs-docker.md @@ -12,7 +12,7 @@ aliases: To deploy the CHT, you should use the technology you are most familiar and comfortable with. It is possible to deploy 20 CHT instances without using Kubernetes. Conversely, if a hosting organisation uses Kubernetes and intends to deploy a single instance of the CHT, that's also fine. > [!TIP] -> [Application development]({{< relref "/hosting/cht/app-developer" >}}) is more straightforward to setup with Docker. +> [Application development](//hosting/cht/app-developer) is more straightforward to setup with Docker. ## Which one to choose? diff --git a/content/en/hosting/cht/kubernetes/_index.md b/content/en/hosting/cht/kubernetes/_index.md index d1f3dd704f..04ad48284e 100644 --- a/content/en/hosting/cht/kubernetes/_index.md +++ b/content/en/hosting/cht/kubernetes/_index.md @@ -8,7 +8,7 @@ aliases: --- {{< callout >}} -Read the [Docker vs Kubernetes]({{< relref "/hosting/cht/kubernetes-vs-docker/" >}}) documentation to select a style of hosting that best fits your CHT deployment. +Read the [Docker vs Kubernetes](//hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. {{< /callout >}} {{< subpages >}} diff --git a/content/en/hosting/cht/migration/preparing-for-4.md b/content/en/hosting/cht/migration/preparing-for-4.md index 5ccdfc1a43..60e83c77c1 100644 --- a/content/en/hosting/cht/migration/preparing-for-4.md +++ b/content/en/hosting/cht/migration/preparing-for-4.md @@ -23,11 +23,11 @@ Upgrading to CHT 4.0 can be quite time consuming, especially for large deployme ## CHT Android v1.0.0+ -This change is straightforward in that CHT 4.x no longer supports versions _before_ `1.0.0`, so deployments need to update their Play Store app. As of this writing, [CHT Android](https://github.com/medic/cht-android/) is at `1.0.4`. See the [Android docs]({{< relref "building/branding/android" >}}) on how to update your app and release it. Note that Google's Play Store can often have delays which deployments have no control over. Again, the sooner you start, the better. +This change is straightforward in that CHT 4.x no longer supports versions _before_ `1.0.0`, so deployments need to update their Play Store app. As of this writing, [CHT Android](https://github.com/medic/cht-android/) is at `1.0.4`. See the [Android docs](/building/branding/android) on how to update your app and release it. Note that Google's Play Store can often have delays which deployments have no control over. Again, the sooner you start, the better. ### Versions in use -After you have published your app, you need to instruct your users to check the Play Store for upgrades. You can then check [CHT Telemetry]({{< relref "technical-overview/data/performance/telemetry" >}}) to see what CHT Android versions are in use. Assuming you have [CHT Sync set up](https://github.com/medic/cht-sync) to pull in your CouchDB data to a PostgreSQL database, this query will list Android versions `count`s for the current year, broken out by `month`, `year` and `version`: +After you have published your app, you need to instruct your users to check the Play Store for upgrades. You can then check [CHT Telemetry](/technical-overview/data/performance/telemetry) to see what CHT Android versions are in use. Assuming you have [CHT Sync set up](https://github.com/medic/cht-sync) to pull in your CouchDB data to a PostgreSQL database, this query will list Android versions `count`s for the current year, broken out by `month`, `year` and `version`: ```sql SELECT @@ -52,7 +52,7 @@ ORDER BY Note that each user can submit many telemetry docs (`count_telemetry`), so the query breaks out users (`count_distinct_users`) and devices (`count_distinct_devices`) for the given month. This means that telemetry counts will be higher than the number of active users. As well, early in the current month, many users may not have had a chance to synchronize their telemetry data yet. For example, this report was run on the 5th of October, so the counts for all three tables are low. Refer to prior months in this case. > [!NOTE] -> In some cases users are accessing the system via the [progressive web app (PWA)]({{< relref "technical-overview/concepts/pwa" >}}) or are online users. We see the `cht_android_version` field is empty in this case. +> In some cases users are accessing the system via the [progressive web app (PWA)](/technical-overview/concepts/pwa) or are online users. We see the `cht_android_version` field is empty in this case. |telemetry_month|cht_android_version|count_distinct_users|count_distinct_devices|count_telemetry| |---------------|-------------------|--------------------|----------------------|---------------| @@ -74,7 +74,7 @@ Note that each user can submit many telemetry docs (`count_telemetry`), so the q ### Active user counts -You can check the [monitoring API]({{< relref "building/reference/api#monitoring" >}}) with `curl` to check active users for the last `30` days. Remember that the users can send a telemetry report once per day, so this active user count will be less than the counts from the query above. +You can check the [monitoring API](/building/reference/api#monitoring) with `curl` to check active users for the last `30` days. Remember that the users can send a telemetry report once per day, so this active user count will be less than the counts from the query above. We'll [use `jq` to filter](https://stedolan.github.io/jq/) out the unrelated metrics. Be sure to replace `CHT-URL-HERE` with your production CHT URL: @@ -173,7 +173,7 @@ CHT 4.0 [upgrades the version of Enketo](https://github.com/medic/cht-core/pull/ You can also manually test your forms on a non-prod CHT instance. It is possible to test your forms against the new Enekto changes without having to uplift your non-prod CHT instance to the new 4.0 architecture. -An easy way of doing this is to use the [CHT 3.x Docker Helper](https://github.com/medic/cht-core/blob/master/scripts/docker-helper/cht-docker-compose.sh) to deploy a 3.x CHT instance. After you have your dev instance up and running, use [Horticulturalist](https://github.com/medic/horticulturalist) to upgrade to the `3.17.0-FR-enketo-upgrade` [feature release]({{< relref "community/contributing/code/releasing/feature_releases" >}}): +An easy way of doing this is to use the [CHT 3.x Docker Helper](https://github.com/medic/cht-core/blob/master/scripts/docker-helper/cht-docker-compose.sh) to deploy a 3.x CHT instance. After you have your dev instance up and running, use [Horticulturalist](https://github.com/medic/horticulturalist) to upgrade to the `3.17.0-FR-enketo-upgrade` [feature release](/community/contributing/code/releasing/feature_releases): ```shell COUCH_URL=https://medic:password@*your-my.local.ip.co-address*:8443/medic horti --local --install=3.17.0-FR-enketo-upgrade-beta.1 @@ -210,7 +210,7 @@ After pushing your app config (see "CHT Conf" above), you can proceed to go thro #### New XPath functions * Custom CHT functions: - * [`add-date`]({{< relref "building/forms/app#add-date" >}}) - Adds the provided number of years/months/days/hours/minutes to a date value. + * [`add-date`](/building/forms/app#add-date) - Adds the provided number of years/months/days/hours/minutes to a date value. * ODK Functions: * Repeats and other node sets: * [`position`](https://docs.getodk.org/form-operators-functions/#position) - Returns the current iteration index within a repeat group. diff --git a/content/en/hosting/cht/requirements.md b/content/en/hosting/cht/requirements.md index 55cfdd1129..c96c72d5a7 100644 --- a/content/en/hosting/cht/requirements.md +++ b/content/en/hosting/cht/requirements.md @@ -15,7 +15,7 @@ aliases: For production CHT deployments, Linux is recommended, with [Ubuntu](https://ubuntu.com/server) the most commonly used. For App Developer Hosting, Linux or macOS may be used. Windows can be used for either, but without recommendation. {{< /callout >}} -Per the [Kubernetes vs Docker]({{< relref "/hosting/cht/kubernetes-vs-docker" >}}) page, CHT Core can be deployed with either Docker or Kubernetes. +Per the [Kubernetes vs Docker](//hosting/cht/kubernetes-vs-docker) page, CHT Core can be deployed with either Docker or Kubernetes. ## App Developer Hosting @@ -23,7 +23,7 @@ This leverages Docker and requires: * 4 GB RAM / 2 CPU / 8 GB SSD * Root Access -* TLS certificates - if using [Docker Helper]({{< relref "/hosting/cht/app-developer#cht-docker-helper-for-4x" >}}) these are provided for you. +* TLS certificates - if using [Docker Helper](//hosting/cht/app-developer#cht-docker-helper-for-4x) these are provided for you. * [Current version](https://docs.docker.com/engine/install/) of `docker` or current version of [Docker Desktop](https://www.docker.com/products/docker-desktop/) both of which include `docker compose`. Note that the older `docker-compose` is [no longer supported](https://www.docker.com/blog/announcing-compose-v2-general-availability/). ## Production Hosting @@ -37,7 +37,7 @@ This leverages Docker and requires: ### Kubernetes -This guide refers to "Kubernetes", and a lightweight orchestrator called [K3s](https://docs.k3s.io/) can be used for bare-metal hosts. The requirements below refer to K3s deployments but can be translated to other Kubernetes hosting. For example, for cloud hosting, CHT is widely deployed with Amazon [Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS). Additionally, the CHT is succesfully deployed in a [large K3s deployment based on VMWare]({{< relref "/hosting/cht/kubernetes/self-hosting-k3s-multinode" >}}). +This guide refers to "Kubernetes", and a lightweight orchestrator called [K3s](https://docs.k3s.io/) can be used for bare-metal hosts. The requirements below refer to K3s deployments but can be translated to other Kubernetes hosting. For example, for cloud hosting, CHT is widely deployed with Amazon [Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS). Additionally, the CHT is succesfully deployed in a [large K3s deployment based on VMWare](//hosting/cht/kubernetes/self-hosting-k3s-multinode). Be sure to see the `cht-deploy` [script](https://github.com/medic/cht-core/tree/master/scripts/deploy) that leverage the `helm` [application](https://helm.sh/docs/intro/install/). diff --git a/content/en/hosting/cht/upgrade-troubleshooting.md b/content/en/hosting/cht/upgrade-troubleshooting.md index 7fa7c411a6..8711c584ee 100644 --- a/content/en/hosting/cht/upgrade-troubleshooting.md +++ b/content/en/hosting/cht/upgrade-troubleshooting.md @@ -17,7 +17,7 @@ aliases: There's a concept of upgrades "getting stuck" which mainly means that after many many hours an upgrade is not making any progress. Most likely, this will manifest as the progress bars in the upgrade admin web UI not increasing and "sticking" at a certain percentage. An alternate possibility is that the progress bars disappear altogether. > [!WARNING] -> All tips apply to both [Docker]({{< relref "/hosting/cht/docker" >}}) and [Kubernetes]({{< relref "/hosting/cht/kubernetes" >}}) based deployments unless otherwise specified. +> All tips apply to both [Docker](//hosting/cht/docker) and [Kubernetes](//hosting/cht/kubernetes) based deployments unless otherwise specified. > All upgrades are expected to succeed without issue. Do not attempt any fixes unless you actively have a problem upgrading. ## Considerations diff --git a/content/en/hosting/couch2pg/couch2pg-setup.md b/content/en/hosting/couch2pg/couch2pg-setup.md index 8793b87422..36a7e2e094 100644 --- a/content/en/hosting/couch2pg/couch2pg-setup.md +++ b/content/en/hosting/couch2pg/couch2pg-setup.md @@ -22,7 +22,7 @@ By the end of the tutorial you should be able to: - Set up a couch2pg service - Run the couch2pg service -[CHT Couch2pg](https://github.com/medic/cht-couch2pg) is a background process that moves data from Couchdb to Postgres through one way replication. It therefore, needs to have full read and write access to both the Postgres Database and Couchdb upstream. It is built in nodejs and can be set up as a background process using systemd. Review this [architecture diagram]({{< relref "technical-overview/architecture#overview" >}}) to get a conceptual understanding of how couch2pg works. +[CHT Couch2pg](https://github.com/medic/cht-couch2pg) is a background process that moves data from Couchdb to Postgres through one way replication. It therefore, needs to have full read and write access to both the Postgres Database and Couchdb upstream. It is built in nodejs and can be set up as a background process using systemd. Review this [architecture diagram](/technical-overview/architecture#overview) to get a conceptual understanding of how couch2pg works. ## Brief Overview of key environmental variables diff --git a/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md b/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md index 2fb0367296..3b4e586c12 100644 --- a/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md +++ b/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md @@ -9,7 +9,7 @@ aliases: - /contribute/medic/data-migration-3x-eks-to-4x-eks --- -Like the [Deploy to EKS guide]({{< relref "/hosting/medic/deploy-on-eks" >}}), this guide is meant for Medic Teammates migrating Medic hosted CHT Core deployments. However, given there may be other users who will benefit from understanding the process, this document is published for all to read. +Like the [Deploy to EKS guide](//hosting/medic/deploy-on-eks), this guide is meant for Medic Teammates migrating Medic hosted CHT Core deployments. However, given there may be other users who will benefit from understanding the process, this document is published for all to read. CHT Core hosting architecture differs entirely between 3.x and 4.x. When both versions are running in Kubernetes, migrating data requires specific steps using the [couchdb-migration](https://github.com/medic/couchdb-migration) tool. This tool interfaces with CouchDB to update shard maps and database metadata. diff --git a/content/en/hosting/monitoring/integration.md b/content/en/hosting/monitoring/integration.md index 9416781a6e..5471c0bb42 100644 --- a/content/en/hosting/monitoring/integration.md +++ b/content/en/hosting/monitoring/integration.md @@ -10,13 +10,13 @@ aliases: ## Going beyond basic setup -After you have done the [setup of CHT Watchdog]({{< relref "/hosting/monitoring/setup.md" >}}) and configured it to run [with TLS and have backups enabled]({{< relref "/hosting/monitoring/production.md" >}}), you may want to extend it to scrape other Prometheus data sources so that Grafana can send alerts on non-CHT Core metrics. +After you have done the [setup of CHT Watchdog](//hosting/monitoring/setup.md) and configured it to run [with TLS and have backups enabled](//hosting/monitoring/production.md), you may want to extend it to scrape other Prometheus data sources so that Grafana can send alerts on non-CHT Core metrics. This guide uses example instances of CHT Core (`cht.example.com`) and CHT Watchdog (`watchdog.example.com`). When deploying, be sure to replace with your own hostnames. ### Default Flow -Let's look at how the default deployment of Watchdog works when configured to only gather metrics from [CHT Core's monitoring API]({{< relref "building/reference/api#get-apiv2monitoring" >}}): +Let's look at how the default deployment of Watchdog works when configured to only gather metrics from [CHT Core's monitoring API](/building/reference/api#get-apiv2monitoring): ```mermaid flowchart LR @@ -64,11 +64,11 @@ By reading this guide you should not only be able to set up cAdvisor, but also b While this is a specific example for cAdvisor, these same steps will be taken to extend Watchdog for other metrics: -1. CHT Core: [Create both cAdvisor and Caddy Docker Compose files]({{< relref "#cadvisor-compose-file" >}}) -2. CHT Core: [Start the Caddy and a cAdvisor containers along with the CHT Core]({{< relref "#start-cadvisor-caddy-and-cht-core-with-docker" >}}) -3. CHT Watchdog: [Adding new scrape and compose configs]({{< relref "#scrape-config" >}}) -4. CHT Watchdog: [Restart the Prometheus and Grafana server to include the new scrape config mounts]({{< relref "#load-new-compose-files-with-existing-ones" >}}) -5. CHT Watchdog: [Importing an existing cAdvisor dashboard from `grafana.com`]({{< relref "#on-cht-watchdog-import-grafana-dashboard" >}}) +1. CHT Core: [Create both cAdvisor and Caddy Docker Compose files](/#cadvisor-compose-file) +2. CHT Core: [Start the Caddy and a cAdvisor containers along with the CHT Core](/#start-cadvisor-caddy-and-cht-core-with-docker) +3. CHT Watchdog: [Adding new scrape and compose configs](/#scrape-config) +4. CHT Watchdog: [Restart the Prometheus and Grafana server to include the new scrape config mounts](/#load-new-compose-files-with-existing-ones) +5. CHT Watchdog: [Importing an existing cAdvisor dashboard from `grafana.com`](/#on-cht-watchdog-import-grafana-dashboard) After completing these steps, we now have Docker metrics we can alert on: @@ -111,7 +111,7 @@ services: #### Caddy Config and Compose files -Like we did in the [TLS section]({{< relref "/hosting/monitoring/production#accessing-grafana-over-tls" >}}), we'll add both a `/home/ubuntu/Caddyfile` and a `/home/ubuntu/cht/compose/caddy-compose.yml`. +Like we did in the [TLS section](//hosting/monitoring/production#accessing-grafana-over-tls), we'll add both a `/home/ubuntu/Caddyfile` and a `/home/ubuntu/cht/compose/caddy-compose.yml`. Starting with the `Caddyfile`, let's assume your server's DNS entry is `cht.example.com`. We can expose cAdvisor's service running on localhost port `8443` with this compose file. This tells Caddy to reverse proxy requests to the public interface to the private Docker network interface on port `8080` where cAdvisor is running: @@ -140,7 +140,7 @@ services: Now that we have all the config files in place, you need to have Docker start everything together. This is so that the containers can see each other on the same `CHT Net` Docker network. You will need to specify each of the compose files every time you start, stop or restart CHT instance so all the services stay running and connected. -Assuming you followed the [production steps]({{< relref "/hosting/cht/docker" >}}) to install the CHT, you use this Compose call to first stop all containers and then start them all up, including the new services: +Assuming you followed the [production steps](//hosting/cht/docker) to install the CHT, you use this Compose call to first stop all containers and then start them all up, including the new services: ```shell cd /home/ubuntu/cht/upgrade-service @@ -176,7 +176,7 @@ services: #### Load new Compose files with existing ones -Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup]({{< relref "/hosting/monitoring/setup" >}}), this would be: +Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](//hosting/monitoring/setup), this would be: ```shell cd ~/cht-monitoring diff --git a/content/en/hosting/monitoring/introduction.md b/content/en/hosting/monitoring/introduction.md index cc938366df..fcd221910f 100644 --- a/content/en/hosting/monitoring/introduction.md +++ b/content/en/hosting/monitoring/introduction.md @@ -10,7 +10,7 @@ aliases: --- {{< callout >}} -Be sure to see how to deploy a solution to [monitor and alert on production CHT instances]({{< relref "/hosting/monitoring/setup.md" >}}). +Be sure to see how to deploy a solution to [monitor and alert on production CHT instances](//hosting/monitoring/setup.md). {{< /callout >}} Each deployment will experience different stresses on its resources. Be sure to tune any alerting levels in the case of a false positive so that you may avoid them in the future. Any thresholds for alerts, and even what is alerted on, is just a guideline, not a guarantee of uptime. @@ -38,7 +38,7 @@ Be sure to monitor important items that the CHT depends on in order to be health ## Inside the CHT -The [monitoring API]({{< relref "building/reference/api#get-apiv2monitoring" >}}) was added in 3.9.0 and does not require any authentication and so can easily be used with third party tools as they do not need a CHT user account. +The [monitoring API](/building/reference/api#get-apiv2monitoring) was added in 3.9.0 and does not require any authentication and so can easily be used with third party tools as they do not need a CHT user account. All metrics need to be monitored over time so that you can easily see longitudinal patterns when debugging an outage or slow down. diff --git a/content/en/hosting/monitoring/postgres-ingest.md b/content/en/hosting/monitoring/postgres-ingest.md index 29760591a4..06f96ab764 100644 --- a/content/en/hosting/monitoring/postgres-ingest.md +++ b/content/en/hosting/monitoring/postgres-ingest.md @@ -10,7 +10,7 @@ aliases: ## Introduction -After [setting up]({{< relref "/hosting/monitoring/setup.md" >}}) your Watchdog instance and [making it production ready]({{< relref "/hosting/monitoring/production.md" >}}), you can include additional custom metrics from your deployment. These metrics should be ingested by Prometheus and then can be used to create new Grafana dashboards and alerts. Example use cases include monitoring and alerting on health metrics like CHW visits per county or household registration rates, etc. +After [setting up](//hosting/monitoring/setup.md) your Watchdog instance and [making it production ready](//hosting/monitoring/production.md), you can include additional custom metrics from your deployment. These metrics should be ingested by Prometheus and then can be used to create new Grafana dashboards and alerts. Example use cases include monitoring and alerting on health metrics like CHW visits per county or household registration rates, etc. This guide will walk you through adding a custom metric from Postgres _data_. The following naming convention is used throughout to reference the relevant server instances: CHT Core (`cht.example.com`), CHT Watchdog (`watchdog.example.com`) and a Postgres server (`db.example.com`). @@ -63,11 +63,11 @@ Adding a custom Postgres metric The following steps are all performed on the CHT Watchdog instance and assume you installed Watchdog in `~/cht-watchdog`. Note that user credentials with READ access to your Postgres server are required. -1. [Prepare query in config file]({{< relref "#prepare-query-in-config-file" >}}) -2. [Adding new scrape config]({{< relref "#adding-new-scrape-config" >}}) -3. [Add new Postgres Exporter]({{< relref "#add-new-postgres-exporter" >}}) -4. [Configure the dashboard]({{< relref "#configure-the-dashboard" >}}) -5. [Optional: Add Dashboard to CHT Dropdown in Grafana]({{< relref "#optional-add-dashboard-to-cht-dropdown-in-grafana" >}}) +1. [Prepare query in config file](/#prepare-query-in-config-file) +2. [Adding new scrape config](/#adding-new-scrape-config) +3. [Add new Postgres Exporter](/#add-new-postgres-exporter) +4. [Configure the dashboard](/#configure-the-dashboard) +5. [Optional: Add Dashboard to CHT Dropdown in Grafana](/#optional-add-dashboard-to-cht-dropdown-in-grafana) ### Prepare query in config file @@ -152,7 +152,7 @@ services: Launch Watchdog with the new compose file -Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup]({{< relref "/hosting/monitoring/setup" >}}), this would be: +Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](//hosting/monitoring/setup), this would be: ```shell cd ~/cht-watchdog diff --git a/content/en/hosting/monitoring/production.md b/content/en/hosting/monitoring/production.md index 4fd4f9bd43..556e48ceb3 100644 --- a/content/en/hosting/monitoring/production.md +++ b/content/en/hosting/monitoring/production.md @@ -17,7 +17,7 @@ When you run CHT Watchdog in production, and it is publicly accessible on the In * ensuring if the server were to fail, you can recover the data -This guide assumes you have already [set up TLS]({{< relref "/hosting/cht/docker/adding-tls-certificates" >}}) on your CHT instance and have gone through [the Setup steps]({{< relref "/hosting/monitoring/setup" >}}) to deploy an instance of CHT Watchdog on server with a static IP and DNS entry, `monitor.example.com` for example. +This guide assumes you have already [set up TLS](//hosting/cht/docker/adding-tls-certificates) on your CHT instance and have gone through [the Setup steps](//hosting/monitoring/setup) to deploy an instance of CHT Watchdog on server with a static IP and DNS entry, `monitor.example.com` for example. > [!WARNING] > Always run Watchdog on a different server than the CHT Core. This ensures Watchdog doesn't fail if the CHT Core server fails and alerts will always be sent. The instructions assume you're connecting over the public Internet and no special VPN or routing is required. diff --git a/content/en/hosting/monitoring/setup.md b/content/en/hosting/monitoring/setup.md index f134e1ec70..a4db88c098 100644 --- a/content/en/hosting/monitoring/setup.md +++ b/content/en/hosting/monitoring/setup.md @@ -115,7 +115,7 @@ docker compose up -d #### CHT Sync Data (Local) -With the [release of 1.1.0](https://github.com/medic/cht-watchdog/releases/tag/1.1.0), Watchdog now supports easily ingesting [CHT Sync]({{< relref "/hosting/analytics" >}}) data read in from a Postgres database (supports Postgres `>= 9.x`). +With the [release of 1.1.0](https://github.com/medic/cht-watchdog/releases/tag/1.1.0), Watchdog now supports easily ingesting [CHT Sync](//hosting/analytics) data read in from a Postgres database (supports Postgres `>= 9.x`). 1. Copy the example config file, so you can add the correct contents in them: ```shell @@ -140,7 +140,7 @@ With the [release of 1.1.0](https://github.com/medic/cht-watchdog/releases/tag/1 #### CHT Sync Data (Remote) -While not the default setup, and not what most deployments need, you may want to set up a way to monitor CHT Sync data without sharing any Postgres credentials. Instead of sharing credentials, you expose an HTTP endpoint that requires no login or password. Of course, similar to CHT Core's [Monitoring API]({{< relref "building/reference/api#get-apiv2monitoring" >}}), this endpoint should be configured to not share sensitive information (since it will be publicly accessible). +While not the default setup, and not what most deployments need, you may want to set up a way to monitor CHT Sync data without sharing any Postgres credentials. Instead of sharing credentials, you expose an HTTP endpoint that requires no login or password. Of course, similar to CHT Core's [Monitoring API](/building/reference/api#get-apiv2monitoring), this endpoint should be configured to not share sensitive information (since it will be publicly accessible). This section has two steps. The first is to expose the password-less metrics endpoint and the second is to scrape it with Prometheus. Here's documentation on how to set up a Kubernetes or Docker endpoint for CHT Sync. @@ -227,7 +227,7 @@ The provisioned alert rules cannot be modified directly. Instead, you can copy t 1. Open the alert rule you would like to modify in the Grafana alert rules UI and select the "Copy" button. 2. Update the copied alert rule with the desired changes and save it into a new Evaluation group. -3. [Remove the provisioned alert]({{< relref "#deleting-provisioned-alert-rules" >}}). +3. [Remove the provisioned alert](/#deleting-provisioned-alert-rules). ##### Configuring Contact Points diff --git a/content/en/reference-apps/maternal-newborn.md b/content/en/reference-apps/maternal-newborn.md index 4861dca254..8f71b73784 100644 --- a/content/en/reference-apps/maternal-newborn.md +++ b/content/en/reference-apps/maternal-newborn.md @@ -34,7 +34,7 @@ The maternal and newborn health workflow ensures that women receive the care tha ## Forms Hierarchy -Once a [hierarchy]({{< relref "building/workflows/hierarchy" >}}) of people and places is established, forms are added at different levels. This diagram indicates the forms that can be filled about a person in the app (in this case, family members at the household level), as well as the person/user who will access these forms and make the reports (CHWs at the CHW Area level). Some forms are accessible as actions from the family member’s profile as actions, others from the CHW’s task list as tasks, and some as either. +Once a [hierarchy](/building/workflows/hierarchy) of people and places is established, forms are added at different levels. This diagram indicates the forms that can be filled about a person in the app (in this case, family members at the household level), as well as the person/user who will access these forms and make the reports (CHWs at the CHW Area level). Some forms are accessible as actions from the family member’s profile as actions, others from the CHW’s task list as tasks, and some as either. {{< figure src="forms-hierarchy.png" link="forms-hierarchy.png" class="right col-12 col-lg-12" >}} diff --git a/content/en/releases/4_11_0.md b/content/en/releases/4_11_0.md index 2cdcff674a..7df6a191da 100644 --- a/content/en/releases/4_11_0.md +++ b/content/en/releases/4_11_0.md @@ -31,7 +31,7 @@ None. The CHT datasource API has been expanded to allow querying places and persons by contact type. ##### Details -See more details in the [API docs]({{< relref "building/reference/api#get-apiv1person" >}}). +See more details in the [API docs](/building/reference/api#get-apiv1person). ### Phone numbers are not required to be checked for duplicates Phone number fields can now be used without automatically checking for duplicates. This can be useful for workflows where users may share a phone or for any workflow where having duplicate phones is possible, and it's undesirable to check for duplicates. diff --git a/content/en/releases/4_12_0.md b/content/en/releases/4_12_0.md index 05309ef2de..cca6e0f311 100644 --- a/content/en/releases/4_12_0.md +++ b/content/en/releases/4_12_0.md @@ -24,7 +24,7 @@ None. This release includes changes to the user interface which will improve the learnability of the CHT by aligning with the look and feel of other android apps. Below is a summary of the changes, all of which were covered in the [July Round-up Call](https://youtube.com/watch?v=NSFRQt378Ls&t=460s): - [Update to the overall CHT app Navigation experience](https://forum.communityhealthtoolkit.org/t/the-ui-evolution-of-the-cht/3515#navigation-6) -- Added the ability to temporarily [opt out]({{< relref "/community/contributing/code/core/feature-flags" >}}) of the new Navigation experience +- Added the ability to temporarily [opt out](//community/contributing/code/core/feature-flags) of the new Navigation experience - [Removal of opt out capabilities for Old Filter and Search](https://forum.communityhealthtoolkit.org/t/feature-removal-opting-out-of-two-ui-changes/3738) - [Removal of opt out capabilities for Old Action Bar](https://forum.communityhealthtoolkit.org/t/feature-removal-opting-out-of-two-ui-changes/3738) @@ -49,18 +49,18 @@ Users with the `can_view_old_navigation` permission will see the previous versio To make way for the updated Navigation, it was necessary to remove the previous opt out capabilities. These two permissions are no longer recognized by the CHT. - `can_view_old_filter_and_search` (introduced in [`3.17.0`]({{% ref "releases/3_17_0.md" %}})) - `can_view_old_action_bar` (introduced in [`4.2.0`]({{% ref "releases/4_2_0.md" %}})) -While it’s not necessary to remove these permissions from your [Roles]({{< relref "building/reference/app-settings/user-roles" >}}), they will no longer be recognized by the CHT and users will automatically see the updates they relate to. +While it’s not necessary to remove these permissions from your [Roles](/building/reference/app-settings/user-roles), they will no longer be recognized by the CHT and users will automatically see the updates they relate to. ### Added storage metrics to monitoring api -To help better track and understand data usage in the CHT, additional metrics were added to the [monitoring api]({{< relref "building/reference/api#monitoring" >}}). The api now reports the following size values for each of the tracked databases and their view indexes: +To help better track and understand data usage in the CHT, additional metrics were added to the [monitoring api](/building/reference/api#monitoring). The api now reports the following size values for each of the tracked databases and their view indexes: - `active` - The size in bytes of live data inside the database/view. - `file` - The size in bytes of the database/view as stored on disk. In addition, the `fragmentation` metric value reported for each database will now factor in the disk usage of all the view indexes for that database. This means that the `fragmentation` value will more accurately represent the total fragmentation of the data in that database. -Support for tracking these new metrics has been added to [CHT Watchdog]({{< relref "technical-overview/architecture/cht-watchdog" >}}) as of the [`1.16.0` release](https://github.com/medic/cht-watchdog/releases/tag/1.16.0). +Support for tracking these new metrics has been added to [CHT Watchdog](/technical-overview/architecture/cht-watchdog) as of the [`1.16.0` release](https://github.com/medic/cht-watchdog/releases/tag/1.16.0). ## And more... diff --git a/content/en/releases/4_19_0.md b/content/en/releases/4_19_0.md index 4311253dec..eacc65b6e2 100644 --- a/content/en/releases/4_19_0.md +++ b/content/en/releases/4_19_0.md @@ -31,7 +31,7 @@ None. {{< figure link="../images/4_19_0-duplicate-contact-screenshot.png" src="../images/4_19_0-duplicate-contact-screenshot.png" >}} -Contacts are created/modified via highly configurable [contact forms]({{< relref "building/forms/contact" >}}). One major challenge when collecting contact data is ensuring users do not inadvertently enter duplicate records for the same contact. +Contacts are created/modified via highly configurable [contact forms](/building/forms/contact). One major challenge when collecting contact data is ensuring users do not inadvertently enter duplicate records for the same contact. The CHT now supports automatically detecting when a contact being created or edited by a user matches an existing contact record. If a duplicate contact is detected, the user will be given the option of proceeding to the profile of the existing contact. Alternatively, the user can choose to override the duplicate detection logic and continue creating/editing the contact as originally intended. See [the documentation]( {{< ref "/building/contact-management/contacts/#duplicate-contact-detection" >}} ) for more details. diff --git a/content/en/releases/4_2_0.md b/content/en/releases/4_2_0.md index a6fde68bde..3f35cb62d4 100644 --- a/content/en/releases/4_2_0.md +++ b/content/en/releases/4_2_0.md @@ -26,7 +26,7 @@ None. The additive actions (creating reports, places, people, etc...) have moved from the bottom action bar to a Floating Action Button that opens a menu with all actions. This change aligns the CHT more closely with Android UX and [material design patterns](https://m3.material.io/components/menus/overview), and applies to the Messages, Reports, and Contacts tab. -NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags]({{< relref "/community/contributing/code/core/feature-flags" >}}) documentation for more information. +NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](//community/contributing/code/core/feature-flags) documentation for more information. {{< cards cols=2 >}} {{< figure src="../images/4_2_0-7998-mobile-fab.png" class="left col-4 col-lg-4" >}} @@ -41,7 +41,7 @@ NOTE: The bottom action bar can be temporarily re-enabled for specific users by The Export, Edit, and Delete actions have moved from the bottom action bar to a new More Option (⋮) menu located on the top right side of the screen. This change aligns the CHT more closely with Android UX and [material design patterns](https://m3.material.io/components/menus/overview), and applies to the Messages, Reports, and Contacts tab. -NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags]({{< relref "/community/contributing/code/core/feature-flags" >}}) documentation for more information. +NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](//community/contributing/code/core/feature-flags) documentation for more information. {{< cards >}} {{< figure src="../images/4_2_0-7872-mobile.png" class="left col-3 col-lg-3" >}} @@ -56,7 +56,7 @@ NOTE: The bottom action bar can be temporarily re-enabled for specific users by ### Training Cards -A new feature was added to help health workers learn about changes to their CHT app remotely, directly in their app. Training Card content might include information about a newly deployed feature, changes to a [care guide]({{< relref "building/care-guides" >}}), or simply a reminder about an underused feature or workflow. You can read more about it in the [Training Cards documentation]({{< relref "building/training/training-cards" >}}) and find some template content in the [resources]({{< relref "building/training/training-cards-resources" >}}) section on the documentation site to help you get started with Training Cards. +A new feature was added to help health workers learn about changes to their CHT app remotely, directly in their app. Training Card content might include information about a newly deployed feature, changes to a [care guide](/building/care-guides), or simply a reminder about an underused feature or workflow. You can read more about it in the [Training Cards documentation](/building/training/training-cards) and find some template content in the [resources](/building/training/training-cards-resources) section on the documentation site to help you get started with Training Cards. {{< figure src="../images/4_2_0-6598-training-deck.png" class="col-12 col-lg-10" >}} @@ -68,15 +68,15 @@ When configured, users will automatically be created when certain types of perso For example, a supervisor could onboard a new CHW just by creating a new person contact for them with a “create contact” form. The new user for the CHW will automatically be created and the CHW will receive an SMS message containing the token login link. This link will allow them to login as the newly created user. -You can read more about it in [the transitions configuration docs]({{< relref "building/reference/app-settings/transitions#create_user_for_contacts" >}})! +You can read more about it in [the transitions configuration docs](/building/reference/app-settings/transitions#create_user_for_contacts)! - [#7753](https://github.com/medic/cht-core/issues/7753): Allow supervisors to create health workers ### Extension libraries -The extension libraries are blocks of code that are cached with the CHT web application giving app developers a powerful tool to extend the CHT. An example of a use for this feature is to provide a function to calculate a risk score based on a machine learning model. The function can then be called passing in values from [app forms]({{< relref "building/forms/app" >}}) and return the result to be stored with the report. +The extension libraries are blocks of code that are cached with the CHT web application giving app developers a powerful tool to extend the CHT. An example of a use for this feature is to provide a function to calculate a risk score based on a machine learning model. The function can then be called passing in values from [app forms](/building/forms/app) and return the result to be stored with the report. -Read more about this feature in the [extension libraries docs]({{< relref "extension-libs" >}}) +Read more about this feature in the [extension libraries docs](/extension-libs) - [#7824](https://github.com/medic/cht-core/issues/7824): Provide a general integration point of arbitrary JS in forms via config diff --git a/content/en/releases/4_3_0.md b/content/en/releases/4_3_0.md index 3a292977bb..6ac785ae61 100644 --- a/content/en/releases/4_3_0.md +++ b/content/en/releases/4_3_0.md @@ -31,7 +31,7 @@ None. ### Adding phone numbers to patients when registering via SMS -The registration transition now supports storing a phone number field for new patients. This is achieved through an additional field in the SMS form, which can be configured to be parsed and validated as a correct and, optionally unique, phone number. You can read more about it in [the registration configuration]({{< relref "building/reference/app-settings/transitions#registration" >}}) +The registration transition now supports storing a phone number field for new patients. This is achieved through an additional field in the SMS form, which can be configured to be parsed and validated as a correct and, optionally unique, phone number. You can read more about it in [the registration configuration](/building/reference/app-settings/transitions#registration) ### Performance improvement for downwards replication @@ -54,7 +54,7 @@ Look at this performance comparison table: ### New Prometheus API endpoint -A new API endpoint now allows exporting API request performance. The output is formatted for the Prometheus Data Model. The endpoint is available without requiring authentication and is used by CHT-Watchdog. [More details are available in API reference docs]({{< relref "building/reference/api#get-apiv1express-metrics" >}}). +A new API endpoint now allows exporting API request performance. The output is formatted for the Prometheus Data Model. The endpoint is available without requiring authentication and is used by CHT-Watchdog. [More details are available in API reference docs](/building/reference/api#get-apiv1express-metrics). ## And more... ### Features diff --git a/content/en/releases/4_5_0.md b/content/en/releases/4_5_0.md index 37d12f6f9b..e99208bb6e 100644 --- a/content/en/releases/4_5_0.md +++ b/content/en/releases/4_5_0.md @@ -42,7 +42,7 @@ The targets UI has been updated to match [material design](https://m3.material.i ### Outbound tasks can be configured on a schedule -The CHT now supports scheduling when outbound push tasks are run based on a cron expression. Read about how to set this up in the [outbound push documentation]({{< relref "building/reference/app-settings/outbound#cron" >}}). +The CHT now supports scheduling when outbound push tasks are run based on a cron expression. Read about how to set this up in the [outbound push documentation](/building/reference/app-settings/outbound#cron). ### Features diff --git a/content/en/releases/4_6_0.md b/content/en/releases/4_6_0.md index 0424327901..f6f3723d69 100644 --- a/content/en/releases/4_6_0.md +++ b/content/en/releases/4_6_0.md @@ -32,7 +32,7 @@ None. ### Allow contact searches in forms to be filtered by descendants of the current contact -A [contact selector]({{< relref "building/forms/configuring/form-inputs#contact-selector" >}}) can be used in forms to allow users to select a contact by searching. In addition to limiting the searchable contacts by their type, now you can configure the search field to only show contacts which are descendants of the current contact. This is useful when you only want to allow a user to select specific contacts (such as members of the current household). Learn how to configure this functionality in [the documentation]({{< relref "building/forms/configuring/form-inputs#loading-descendants-of-the-current-contact" >}}). +A [contact selector](/building/forms/configuring/form-inputs#contact-selector) can be used in forms to allow users to select a contact by searching. In addition to limiting the searchable contacts by their type, now you can configure the search field to only show contacts which are descendants of the current contact. This is useful when you only want to allow a user to select specific contacts (such as members of the current household). Learn how to configure this functionality in [the documentation](/building/forms/configuring/form-inputs#loading-descendants-of-the-current-contact). - [#8074](https://github.com/medic/cht-core/issues/8074): Support filtering contact search in forms by descendants of the current contact diff --git a/content/en/releases/4_7_0.md b/content/en/releases/4_7_0.md index 558c9a5fa0..a9752b255d 100644 --- a/content/en/releases/4_7_0.md +++ b/content/en/releases/4_7_0.md @@ -14,7 +14,7 @@ aliases: > [!CAUTION] > Due to a critical bug that prevented further upgrades from `4.7.0`, we have have removed `4.7.0` from our releases list, so that it will not be possible to upgrade to `4.7.0`. -> The bug has been fixed in [`4.7.1`]({{< relref "releases/4_7_1" >}}). +> The bug has been fixed in [`4.7.1`](/releases/4_7_1). > If you have already installed or upgraded to `4.7.0`, connect with us on the [forum](https://forum.communityhealthtoolkit.org/t/high-priority-issue-in-cht-core-4-7-0/3512) to get unblocked. > We apologise for the inconvenience. diff --git a/content/en/technical-overview/architecture/cht-android.md b/content/en/technical-overview/architecture/cht-android.md index a6d7c18f7d..ef5b177946 100644 --- a/content/en/technical-overview/architecture/cht-android.md +++ b/content/en/technical-overview/architecture/cht-android.md @@ -8,7 +8,7 @@ aliases: - /core/overview/cht-android/ --- -The [cht-android](https://github.com/medic/cht-android) application is a thin Android wrapper to load the [CHT Core Framework web application]({{< relref "technical-overview/architecture/cht-core" >}}) in a Webview native container. +The [cht-android](https://github.com/medic/cht-android) application is a thin Android wrapper to load the [CHT Core Framework web application](/technical-overview/architecture/cht-core) in a Webview native container. It consists of “flavored” configurations, where each “flavor” or “brand” is an app, which allows the application to be hardcoded to a specific CHT deployment and have a partner-specific logo and display name. The app also provides some deeper integration with other Android apps and native phone functions that are otherwise unavailable to webapps. diff --git a/content/en/technical-overview/architecture/cht-conf.md b/content/en/technical-overview/architecture/cht-conf.md index edeb438889..e0e38d24a7 100644 --- a/content/en/technical-overview/architecture/cht-conf.md +++ b/content/en/technical-overview/architecture/cht-conf.md @@ -12,7 +12,7 @@ aliases: [CHT Conf](https://github.com/medic/cht-conf) is a command-line interface tool to manage and configure apps built using the [CHT Core Framework](https://github.com/medic/cht-core). ## Installation -Read more about setting up [CHT Conf]({{< relref "community/contributing/code/cht-conf" >}}). +Read more about setting up [CHT Conf](/community/contributing/code/cht-conf). ## Currently Supported The different items that are supported by CHT Conf include: diff --git a/content/en/technical-overview/architecture/cht-core.md b/content/en/technical-overview/architecture/cht-core.md index 0049e54abf..19443fa169 100644 --- a/content/en/technical-overview/architecture/cht-core.md +++ b/content/en/technical-overview/architecture/cht-core.md @@ -95,7 +95,7 @@ The CHT Core Framework provides two web applications: the [CHT Web App]({{% ref #### CHT Web Application -The CHT Web Application is used by Community Health Workers and provides a large variety of [features]({{< relref "building" >}}). View the source code in [our GitHub repository](https://github.com/medic/cht-core/tree/master/webapp). +The CHT Web Application is used by Community Health Workers and provides a large variety of [features](/building). View the source code in [our GitHub repository](https://github.com/medic/cht-core/tree/master/webapp). ##### Technology diff --git a/content/en/technical-overview/architecture/cht-interoperability.md b/content/en/technical-overview/architecture/cht-interoperability.md index f6ede78c55..35edcc619f 100644 --- a/content/en/technical-overview/architecture/cht-interoperability.md +++ b/content/en/technical-overview/architecture/cht-interoperability.md @@ -11,4 +11,4 @@ aliases: - /core/overview/interoperability/ --- -[CHT Interoperability]({{< relref "/building/interoperability/" >}}) refers to the ability of different health information systems and applications to communicate with each other and exchange data seamlessly. With interoperability, patient information can be seen, exchanged, and used across different platforms. The information/data exchanged has to be understood across the different software for these systems to become interoperable. This is different from _integration_ which requires custom development to connect two specific systems. +[CHT Interoperability](//building/interoperability/) refers to the ability of different health information systems and applications to communicate with each other and exchange data seamlessly. With interoperability, patient information can be seen, exchanged, and used across different platforms. The information/data exchanged has to be understood across the different software for these systems to become interoperable. This is different from _integration_ which requires custom development to connect two specific systems. diff --git a/content/en/technical-overview/architecture/cht-sync.md b/content/en/technical-overview/architecture/cht-sync.md index 4caa609d5b..e1562a239b 100644 --- a/content/en/technical-overview/architecture/cht-sync.md +++ b/content/en/technical-overview/architecture/cht-sync.md @@ -16,7 +16,7 @@ aliases: CHT Sync is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It combines several technologies to achieve this synchronization and provides an efficient workflow for data processing and visualization. The synchronization occurs in near real-time, ensuring that the data displayed on dashboards is up-to-date. -Read more about setting up [CHT Sync]({{< relref "/hosting/analytics" >}}). +Read more about setting up [CHT Sync](//hosting/analytics). @@ -45,5 +45,5 @@ We recommend [Apache Superset](https://superset.apache.org/) as the Data Visuali ### CHT Core Framework & CouchDB -For more information on these technologies, see [CHT Core overview]({{< relref "technical-overview/architecture" >}}). +For more information on these technologies, see [CHT Core overview](/technical-overview/architecture). diff --git a/content/en/technical-overview/architecture/cht-watchdog.md b/content/en/technical-overview/architecture/cht-watchdog.md index 0a608009bc..a6041a640b 100644 --- a/content/en/technical-overview/architecture/cht-watchdog.md +++ b/content/en/technical-overview/architecture/cht-watchdog.md @@ -12,7 +12,7 @@ aliases: - /technical-overview/cht-watchdog/ --- -CHT Watchdog is deployed on a separate server so that you can watch for, and alert on, any critical issues with the CHT Core. Read more about [setting up CHT Watchdog]({{< relref "/hosting/monitoring/setup" >}}). +CHT Watchdog is deployed on a separate server so that you can watch for, and alert on, any critical issues with the CHT Core. Read more about [setting up CHT Watchdog](//hosting/monitoring/setup). @@ -31,7 +31,7 @@ CHT Watchdog is deployed on a separate server so that you can watch for, and ale ### JSON Exporter -[JSON Exporter](https://github.com/prometheus-community/json_exporter) is a wrapper utility to convert a JSON API to be compatible with Prometheus scrape config. This is used to convert the CHT [Monitoring API's JSON]({{< relref "building/reference/api#get-apiv2monitoring" >}}). +[JSON Exporter](https://github.com/prometheus-community/json_exporter) is a wrapper utility to convert a JSON API to be compatible with Prometheus scrape config. This is used to convert the CHT [Monitoring API's JSON](/building/reference/api#get-apiv2monitoring). ### Postgres Exporter @@ -39,4 +39,4 @@ CHT Watchdog is deployed on a separate server so that you can watch for, and ale ### CHT Core Framework & RDBMS -For more information on these technologies, see [CHT Core overview]({{< relref "technical-overview/architecture" >}}). +For more information on these technologies, see [CHT Core overview](/technical-overview/architecture). diff --git a/content/en/technical-overview/architecture/overview.md b/content/en/technical-overview/architecture/overview.md index d982281a01..7fddf567e6 100644 --- a/content/en/technical-overview/architecture/overview.md +++ b/content/en/technical-overview/architecture/overview.md @@ -69,7 +69,7 @@ A command-line interface tool to manage and configure CHT application. The A suite of tools for extracting and normalizing data from the Core Framework's CouchDB, and rendering the data in analytics dashboards to visualize key data for a CHT deployment. -Read more detail on the CHT Sync [overview page]({{< relref "/technical-overview/architecture/cht-sync" >}}), the [GitHub repository](https://github.com/medic/cht-sync), or the [technical overview](/technical-overview/architecture/cht-sync). +Read more detail on the CHT Sync [overview page](//technical-overview/architecture/cht-sync), the [GitHub repository](https://github.com/medic/cht-sync), or the [technical overview](/technical-overview/architecture/cht-sync). ## CHT Watchdog @@ -77,7 +77,7 @@ Monitoring and alerting for the CHT Core Framework to ensure CHWs are able to de ## CHT Android -CHT Web Application works in the browser or wrapped in the [CHT Android]({{< relref "/technical-overview/architecture/cht-android" >}}) app which allows for project branding, sets the project URL, and hides browser elements like the URL bar. The app also provides some deeper integration with other android apps and native phone functions that are otherwise unavailable to webapps. +CHT Web Application works in the browser or wrapped in the [CHT Android](//technical-overview/architecture/cht-android) app which allows for project branding, sets the project URL, and hides browser elements like the URL bar. The app also provides some deeper integration with other android apps and native phone functions that are otherwise unavailable to webapps. ## CHT Gateway @@ -85,8 +85,8 @@ CHT Web Application works in the browser or wrapped in the [CHT Android]({{< rel ## CHT Interoperability -[CHT Interoperability]({{< relref "technical-overview/architecture/cht-interoperability" >}}) implements interoperability between the CHT and other health information systems based on OpenHIE architecture and HL7 FHIR messaging format. +[CHT Interoperability](/technical-overview/architecture/cht-interoperability) implements interoperability between the CHT and other health information systems based on OpenHIE architecture and HL7 FHIR messaging format. ## CHT User Management Tool -[CHT User Management Tool]({{< relref "building/contact-management/user-management-tool" >}}) is a web application that works with the CHT to decentralize the user management. +[CHT User Management Tool](/building/contact-management/user-management-tool) is a web application that works with the CHT to decentralize the user management. diff --git a/content/en/technical-overview/concepts/offline-first.md b/content/en/technical-overview/concepts/offline-first.md index a5e045fb9e..10f4f8a30c 100644 --- a/content/en/technical-overview/concepts/offline-first.md +++ b/content/en/technical-overview/concepts/offline-first.md @@ -43,7 +43,7 @@ Once the application has started up it needs data to be useful. This data falls Both of these types of data are cached on the device because they are required for the user to do their job. The CHT Core Framework uses [PouchDB](https://pouchdb.com/) to store the data on the device's disk. Once cached, when the application starts up the code is executed, which reads the data, allowing the user to do their job regardless of the quality of their internet connection. -If the user creates new patient data by registering a family or completing a task the application stores this in the phone's cache and attempts to submit this to the server. Periodically the application checks to see if there is new data on the server that is relevant to the user and if so, it updates the cache. This process of sending and receiving data updates is called [replication]({{< relref "technical-overview/data/performance/replication" >}}), and is performed without interrupting the user from their work. +If the user creates new patient data by registering a family or completing a task the application stores this in the phone's cache and attempts to submit this to the server. Periodically the application checks to see if there is new data on the server that is relevant to the user and if so, it updates the cache. This process of sending and receiving data updates is called [replication](/technical-overview/data/performance/replication), and is performed without interrupting the user from their work. ## FAQs from CHT contributors diff --git a/content/en/technical-overview/concepts/pwa.md b/content/en/technical-overview/concepts/pwa.md index 5413f811c2..4dd34f41ae 100644 --- a/content/en/technical-overview/concepts/pwa.md +++ b/content/en/technical-overview/concepts/pwa.md @@ -31,7 +31,7 @@ Certain features are only available with an Android application, including integ ## How to distribute a CHT app as a PWA -1. Ensure branding configuration is complete. Without this the browser won't recognize the CHT as a PWA and installation will not be possible. Specifically the app will need a `title` and `icon` as these are used for the icon on the home screen. To set this up, follow the instructions on the [branding page]({{< relref "building/branding/application-graphics#1-site-branding" >}}). +1. Ensure branding configuration is complete. Without this the browser won't recognize the CHT as a PWA and installation will not be possible. Specifically the app will need a `title` and `icon` as these are used for the icon on the home screen. To set this up, follow the instructions on the [branding page](/building/branding/application-graphics#1-site-branding). 2. In Chrome or Firefox go to the application URL, log in, and wait for the webapp to finish loading completely. 3. Follow these [instructions for PWA installation](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Add_to_home_screen). diff --git a/content/en/technical-overview/data/analytics/data-flows-for-analytics.md b/content/en/technical-overview/data/analytics/data-flows-for-analytics.md index 24d4d1a8eb..daa430f3a6 100644 --- a/content/en/technical-overview/data/analytics/data-flows-for-analytics.md +++ b/content/en/technical-overview/data/analytics/data-flows-for-analytics.md @@ -51,7 +51,7 @@ Ultimately all the data ends up in a CouchDB instance deployed in the cloud whet #### 2. Data Transformation -[CHT Sync]({{< relref "technical-overview/architecture/cht-sync" >}}) is used to move data from CouchDB to a relational database, PostgreSQL in this case. The choice of PostgreSQL for analytics dashboard data sources is to allow use of the more familiar SQL querying. It is an open source tool that can be [easily deployed]({{< ref "/hosting/analytics" >}}). When deployed the service uses [CouchDB's changes feed](https://docs.couchdb.org/en/stable/api/database/changes.html) which allows capturing of everything happening in CouchDB in incremental updates. It is run and monitored by the operating system where it is configured to fetch data at a configurable interval. +[CHT Sync](/technical-overview/architecture/cht-sync) is used to move data from CouchDB to a relational database, PostgreSQL in this case. The choice of PostgreSQL for analytics dashboard data sources is to allow use of the more familiar SQL querying. It is an open source tool that can be [easily deployed]({{< ref "/hosting/analytics" >}}). When deployed the service uses [CouchDB's changes feed](https://docs.couchdb.org/en/stable/api/database/changes.html) which allows capturing of everything happening in CouchDB in incremental updates. It is run and monitored by the operating system where it is configured to fetch data at a configurable interval. Data copied over to PostgreSQL is first stored as raw json (document) making use of PostgreSQL's jsonb data type to create an exact replica of a CouchDB database. From this, default views are created at deployment of the service and refreshed during every subsequent run. Additional custom materialized views created later are also refreshed at this time. From 60ff0fa5c5d25d69dba73d7dfc12ea2da278ed46 Mon Sep 17 00:00:00 2001 From: Andra Blaj Date: Fri, 3 Oct 2025 14:30:24 +0300 Subject: [PATCH 2/5] fix section links --- .../en/building/forms/_partial_expression_functions.md | 2 +- content/en/building/forms/contact.md | 4 ++-- content/en/building/training/users-bulk-load.md | 2 +- .../contributing/code/test-data/csv-to-docs.md | 2 +- content/en/hosting/cht/docker/backups.md | 6 +++--- content/en/hosting/monitoring/integration.md | 10 +++++----- content/en/hosting/monitoring/postgres-ingest.md | 10 +++++----- content/en/hosting/monitoring/setup.md | 2 +- 8 files changed, 19 insertions(+), 19 deletions(-) diff --git a/content/en/building/forms/_partial_expression_functions.md b/content/en/building/forms/_partial_expression_functions.md index 8eff9f976d..26b38e2548 100644 --- a/content/en/building/forms/_partial_expression_functions.md +++ b/content/en/building/forms/_partial_expression_functions.md @@ -13,7 +13,7 @@ The following functions are available for use in JavaScript expressions: | `ageInMonth(contact)` | Returns the current age of the given contact in months. | | `ageInYears(contact)` | Returns the current age of the given contact in years. | | `levenshteinEq(string0, string1, threshold = 3)` | _(Added `4.19.0`)_ Returns `true` if the [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance) between the given strings is less than or equal to the given threshold. Otherwise `false`. | -| `normalizedLevenshteinEq(string0, string1, threshold = 0.42857142857142855)` | _(Added `4.19.0`)_ Similar to the `levenshteinEq` function except the distance value is "normalized" (by dividing by the length of the longest string) before comparing to the threshold. [See below](/#normalized-levenshtein-equality) for more details. | +| `normalizedLevenshteinEq(string0, string1, threshold = 0.42857142857142855)` | _(Added `4.19.0`)_ Similar to the `levenshteinEq` function except the distance value is "normalized" (by dividing by the length of the longest string) before comparing to the threshold. [See below](#normalized-levenshtein-equality) for more details. | #### Normalized Levenshtein Equality diff --git a/content/en/building/forms/contact.md b/content/en/building/forms/contact.md index bac4f269c6..0648df2004 100644 --- a/content/en/building/forms/contact.md +++ b/content/en/building/forms/contact.md @@ -55,10 +55,10 @@ The meta information in the `{contact_type_id}-{create|edit}.properties.json` fi | Property | Description | required | |------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| | `context` | _Added in `3.10`._ The contact form context defines when the form should be available in the app. Note: this applies only to the contact form, not the contacts themselves. | no | -| `context.expression` | A JavaScript expression evaluated when a contact profile is viewed. This can limit which users have access to the contact form. [See below](/#context-expression) for more details. | no | +| `context.expression` | A JavaScript expression evaluated when a contact profile is viewed. This can limit which users have access to the contact form. [See below](#context-expression) for more details. | no | | `context.permission` | String permission key required to allow the user to view and submit this form. If blank, this defaults to allowing all access. | no | | `duplicate_check` | _Added in `4.19`._ Allows for configuring or disabling the [duplicate detection logic]({{< ref "building/contact-management/contacts#duplicate-contact-detection" >}}) for a particular contact type. | no | -| `duplicate_check.expression` | A JavaScript expression evaluated when submitting the contact form. The expression defines the logic used for determining when a contact is considered to be a duplicate. [See below](/#duplicate-check-expression) for more details. | no | +| `duplicate_check.expression` | A JavaScript expression evaluated when submitting the contact form. The expression defines the logic used for determining when a contact is considered to be a duplicate. [See below](#duplicate-check-expression) for more details. | no | | `duplicate_check.disabled` | Boolean determining if the duplicate check should be run when submitting this contact form. Default is `false`. | no | #### Context Expression diff --git a/content/en/building/training/users-bulk-load.md b/content/en/building/training/users-bulk-load.md index 0f58097373..e45703529c 100644 --- a/content/en/building/training/users-bulk-load.md +++ b/content/en/building/training/users-bulk-load.md @@ -155,7 +155,7 @@ Add some new rows at the bottom (item 1), enter the new place name in column A ( ## Configuring custom places types -The third use case mentioned in the [workbook instructions section](/#workbook-instructions) links to a Google Sheets to create user places alongside their account and their contact. This works out of the box with the `default` CHT configuration but will require adjustments to be made in the `place.type_VLOOKUP` spreadsheet when dealing with a CHT configuration with custom places types. +The third use case mentioned in the [workbook instructions section](#workbook-instructions) links to a Google Sheets to create user places alongside their account and their contact. This works out of the box with the `default` CHT configuration but will require adjustments to be made in the `place.type_VLOOKUP` spreadsheet when dealing with a CHT configuration with custom places types. The `place.type_VLOOKUP` spreadsheet has two columns that contain the name of the places types set in the [`.contact_types[]`]({{< relref "building/reference/app-settings/hierarchy" >}}) property of your `app_settings.json` and their respective IDs. The place type name is used by the `User-Place-Type:excluded` column in the `contact.chw` spreadsheet to provide a user-friendly way to pick a place with autocompletion. You will want to keep this spreadsheet in sync with your CHT configuration to create users' places. diff --git a/content/en/community/contributing/code/test-data/csv-to-docs.md b/content/en/community/contributing/code/test-data/csv-to-docs.md index 6c3915eb06..dd9a9a2622 100644 --- a/content/en/community/contributing/code/test-data/csv-to-docs.md +++ b/content/en/community/contributing/code/test-data/csv-to-docs.md @@ -348,7 +348,7 @@ To fetch the files from Google Drive run the `fetch-csvs-from-google-drive` acti #### Linking to Google Drive -The file `csvs-on-google-drive.json` in your project's home directory will consist of a key value pair for each CSV file. The keys must be the filename where the CSV will be stored locally — see the CSV [file documentation above](/#creating-csv-files-for-contacts-reports) for the notation. The value of each key must be the ID of the corresponding file in Google Drive — the ID can be obtained from the URL eg `https://docs.google.com/spreadsheets/d/{FILE_ID}/edit`. +The file `csvs-on-google-drive.json` in your project's home directory will consist of a key value pair for each CSV file. The keys must be the filename where the CSV will be stored locally — see the CSV [file documentation above](#creating-csv-files-for-contacts-reports) for the notation. The value of each key must be the ID of the corresponding file in Google Drive — the ID can be obtained from the URL eg `https://docs.google.com/spreadsheets/d/{FILE_ID}/edit`. ```json { diff --git a/content/en/hosting/cht/docker/backups.md b/content/en/hosting/cht/docker/backups.md index 840b79ea17..2a36557708 100644 --- a/content/en/hosting/cht/docker/backups.md +++ b/content/en/hosting/cht/docker/backups.md @@ -76,7 +76,7 @@ Assuming your CouchDB is stored in `/home/ubuntu/cht/couchdb`, you should use th 1. While you don't need to stop CouchDB to back it up, ensure you follow best practices to back it up. See the [CouchDB site](https://docs.couchdb.org/en/stable/maintenance/backups.html) for more info. Note it is NOT recommended to use replication for backup. 2. It is strongly recommended you encrypt your backups given the sensitivity of the contents. Do this now before copying the backup files to their long term location. -3. Backup the CouchDB files using the [software specified above](/#backup-software) +3. Backup the CouchDB files using the [software specified above](#backup-software) ## Docker Compose files @@ -92,7 +92,7 @@ All compose files, and the corresponding `.env` file, are in these three locatio While all three of these are trivial to recreate by downloading them again, they may change over time so should be archived with your CouchDB data. Further, when there's been a critical failure of a production CHT instance, you want to be sure to make the restore process as speedy as possible. -As all of these files are only read when Docker first loads a service, you can simply copy them whenever you want without stopping any of the CHT services. They should be copied with the same frequency and put in the same location as the CouchDB data using the [backup software specified above](/#backup-software). +As all of these files are only read when Docker first loads a service, you can simply copy them whenever you want without stopping any of the CHT services. They should be copied with the same frequency and put in the same location as the CouchDB data using the [backup software specified above](#backup-software). ## TLS certificates @@ -108,7 +108,7 @@ Like the compose files, the TLS certificate files can easily be regenerated or r docker cp cht_nginx_1:/etc/nginx/private/key.pem . docker cp cht_nginx_1:/etc/nginx/private/cert.pem . ``` -2. Back the up to the same location and frequency as the CouchDB data using the [backup software specified above](/#backup-software). +2. Back the up to the same location and frequency as the CouchDB data using the [backup software specified above](#backup-software). ## Testing backups diff --git a/content/en/hosting/monitoring/integration.md b/content/en/hosting/monitoring/integration.md index 5471c0bb42..dab3d2ee16 100644 --- a/content/en/hosting/monitoring/integration.md +++ b/content/en/hosting/monitoring/integration.md @@ -64,11 +64,11 @@ By reading this guide you should not only be able to set up cAdvisor, but also b While this is a specific example for cAdvisor, these same steps will be taken to extend Watchdog for other metrics: -1. CHT Core: [Create both cAdvisor and Caddy Docker Compose files](/#cadvisor-compose-file) -2. CHT Core: [Start the Caddy and a cAdvisor containers along with the CHT Core](/#start-cadvisor-caddy-and-cht-core-with-docker) -3. CHT Watchdog: [Adding new scrape and compose configs](/#scrape-config) -4. CHT Watchdog: [Restart the Prometheus and Grafana server to include the new scrape config mounts](/#load-new-compose-files-with-existing-ones) -5. CHT Watchdog: [Importing an existing cAdvisor dashboard from `grafana.com`](/#on-cht-watchdog-import-grafana-dashboard) +1. CHT Core: [Create both cAdvisor and Caddy Docker Compose files]cadvisor-compose-file) +2. CHT Core: [Start the Caddy and a cAdvisor containers along with the CHT Core](#start-cadvisor-caddy-and-cht-core-with-docker) +3. CHT Watchdog: [Adding new scrape and compose configs](#scrape-config) +4. CHT Watchdog: [Restart the Prometheus and Grafana server to include the new scrape config mounts](#load-new-compose-files-with-existing-ones) +5. CHT Watchdog: [Importing an existing cAdvisor dashboard from `grafana.com`](#on-cht-watchdog-import-grafana-dashboard) After completing these steps, we now have Docker metrics we can alert on: diff --git a/content/en/hosting/monitoring/postgres-ingest.md b/content/en/hosting/monitoring/postgres-ingest.md index 06f96ab764..226d76085c 100644 --- a/content/en/hosting/monitoring/postgres-ingest.md +++ b/content/en/hosting/monitoring/postgres-ingest.md @@ -63,11 +63,11 @@ Adding a custom Postgres metric The following steps are all performed on the CHT Watchdog instance and assume you installed Watchdog in `~/cht-watchdog`. Note that user credentials with READ access to your Postgres server are required. -1. [Prepare query in config file](/#prepare-query-in-config-file) -2. [Adding new scrape config](/#adding-new-scrape-config) -3. [Add new Postgres Exporter](/#add-new-postgres-exporter) -4. [Configure the dashboard](/#configure-the-dashboard) -5. [Optional: Add Dashboard to CHT Dropdown in Grafana](/#optional-add-dashboard-to-cht-dropdown-in-grafana) +1. [Prepare query in config file](#prepare-query-in-config-file) +2. [Adding new scrape config](#adding-new-scrape-config) +3. [Add new Postgres Exporter](#add-new-postgres-exporter) +4. [Configure the dashboard](#configure-the-dashboard) +5. [Optional: Add Dashboard to CHT Dropdown in Grafana](#optional-add-dashboard-to-cht-dropdown-in-grafana) ### Prepare query in config file diff --git a/content/en/hosting/monitoring/setup.md b/content/en/hosting/monitoring/setup.md index a4db88c098..78b374f156 100644 --- a/content/en/hosting/monitoring/setup.md +++ b/content/en/hosting/monitoring/setup.md @@ -227,7 +227,7 @@ The provisioned alert rules cannot be modified directly. Instead, you can copy t 1. Open the alert rule you would like to modify in the Grafana alert rules UI and select the "Copy" button. 2. Update the copied alert rule with the desired changes and save it into a new Evaluation group. -3. [Remove the provisioned alert](/#deleting-provisioned-alert-rules). +3. [Remove the provisioned alert](#deleting-provisioned-alert-rules). ##### Configuring Contact Points From 62dc5011ec3ddaa4fff69734e27002008ae702ba Mon Sep 17 00:00:00 2001 From: Andra Blaj Date: Fri, 3 Oct 2025 14:31:47 +0300 Subject: [PATCH 3/5] fix more links --- .../en/building/interoperability/cht-config.md | 2 +- content/en/building/local-setup.md | 6 +++--- content/en/building/login.md | 2 +- content/en/building/reference/api.md | 2 +- .../building/reference/app-settings/outbound.md | 2 +- content/en/building/training/users-bulk-load.md | 2 +- .../contributing/code/core/dev-environment.md | 4 ++-- .../contributing/disclosing-vulnerabilities.md | 2 +- content/en/hosting/_index.md | 4 ++-- content/en/hosting/analytics/_index.md | 2 +- .../en/hosting/analytics/building-dbt-models.md | 10 +++++----- .../analytics/couch2pg-to-cht-sync-migration.md | 16 ++++++++-------- content/en/hosting/analytics/dashboards.md | 2 +- .../hosting/analytics/environment-variables.md | 6 +++--- .../en/hosting/analytics/setup-docker-compose.md | 16 ++++++++-------- content/en/hosting/analytics/setup-kubernetes.md | 10 +++++----- content/en/hosting/analytics/tuning-dbt.md | 4 ++-- content/en/hosting/cht/_index.md | 4 ++-- content/en/hosting/cht/app-developer.md | 6 +++--- content/en/hosting/cht/considerations.md | 4 ++-- content/en/hosting/cht/docker/_index.md | 2 +- .../cht/docker/adding-tls-certificates.md | 2 +- content/en/hosting/cht/docker/backups.md | 2 +- content/en/hosting/cht/docker/installation.md | 6 +++--- content/en/hosting/cht/kubernetes-vs-docker.md | 2 +- content/en/hosting/cht/kubernetes/_index.md | 2 +- content/en/hosting/cht/requirements.md | 6 +++--- .../en/hosting/cht/upgrade-troubleshooting.md | 2 +- .../medic/data-migration-3x-eks-to-4x-eks.md | 2 +- content/en/hosting/monitoring/integration.md | 8 ++++---- content/en/hosting/monitoring/introduction.md | 2 +- content/en/hosting/monitoring/postgres-ingest.md | 4 ++-- content/en/hosting/monitoring/production.md | 2 +- content/en/hosting/monitoring/setup.md | 2 +- content/en/releases/4_12_0.md | 2 +- content/en/releases/4_2_0.md | 4 ++-- .../architecture/cht-interoperability.md | 2 +- .../technical-overview/architecture/cht-sync.md | 2 +- .../architecture/cht-watchdog.md | 2 +- .../technical-overview/architecture/overview.md | 4 ++-- 40 files changed, 83 insertions(+), 83 deletions(-) diff --git a/content/en/building/interoperability/cht-config.md b/content/en/building/interoperability/cht-config.md index 57ec7cb5fc..52dd91f8e9 100644 --- a/content/en/building/interoperability/cht-config.md +++ b/content/en/building/interoperability/cht-config.md @@ -172,7 +172,7 @@ In this example, a `danger signs` question is converted into `Observations` wher ## Inbound Patients It is also possbile to create patients in the CHT from patients that were created in external systems. -Patients in CHT applications are represented as [contacts](//building/contact-management/contacts), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`. +Patients in CHT applications are represented as [contacts](/building/contact-management/contacts), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`. To create data in CHT, a mediator converts a FHIR `Patient` to a json object that it submits as a request to [the records API](/building/reference/api/#records). This requires a [form](/building/reference/app-settings/forms/) to be configured in the CHT; the incoming data will be saved as a report. diff --git a/content/en/building/local-setup.md b/content/en/building/local-setup.md index efde5f5f18..fe6125b2f8 100644 --- a/content/en/building/local-setup.md +++ b/content/en/building/local-setup.md @@ -38,7 +38,7 @@ CHT apps can be built on your local system (with the necessary libraries install Before you begin, ensure you have the following tools: - [git](https://git-scm.com/downloads) or the [Github Desktop](https://desktop.github.com/) -- [docker and docker compose](//hosting/cht/requirements#docker). +- [docker and docker compose](/hosting/cht/requirements#docker). ### Installing Docker @@ -170,7 +170,7 @@ To open a terminal running on you _host environment_ in VS Code, open the Comman When using `cht-conf` within a Docker container to connect to a CHT instance that is running on your local machine (e.g. a development instance), you cannot use the `--local` flag or `localhost` in your `--url` parameter (since these will be interpreted as "local to the container"). -It is recommended to run a local CHT instance using the [CHT Docker Helper script](//hosting/cht/app-developer#cht-docker-helper-for-4x). You can connect to the resulting `...local-ip.medicmobile.org` URL from the Docker container (or the VS Code terminal). (Just make sure the port your CHT instance is hosted on is not blocked by your firewall). +It is recommended to run a local CHT instance using the [CHT Docker Helper script](/hosting/cht/app-developer#cht-docker-helper-for-4x). You can connect to the resulting `...local-ip.medicmobile.org` URL from the Docker container (or the VS Code terminal). (Just make sure the port your CHT instance is hosted on is not blocked by your firewall). --- @@ -178,7 +178,7 @@ It is recommended to run a local CHT instance using the [CHT Docker Helper scrip Now that you have the dependent tools and software installed, you are ready to set up your local CHT environment. -Refer to the [App Developer Hosting Guide](//hosting/cht/app-developer) for instructions on how to deploy a local CHT instance. +Refer to the [App Developer Hosting Guide](/hosting/cht/app-developer) for instructions on how to deploy a local CHT instance. Note that the first time you run your CHT instance it may take a while. In case you run into issues running your docker file, ensure that the following setting in Docker is checked. > Settings >> General >> Use Docker Compose V2 diff --git a/content/en/building/login.md b/content/en/building/login.md index ec736ed284..9400db7c09 100644 --- a/content/en/building/login.md +++ b/content/en/building/login.md @@ -38,7 +38,7 @@ To enhance the security of CHT applications, users logging in for the first time {{< figure src="password-change.png" link="password-change.png" class="col-12 col-lg-12" >}} This feature is enabled by default because it encourages best practices. However, only new users will be prompted to go through this flow or those users whose passwords have been reset by the system administration. -Projects can disable this feature by enabling the `can_skip_password_change` [permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}}). This permission is a [feature flag](//community/contributing/code/core/feature-flags) and will be removed in a later CHT release. +Projects can disable this feature by enabling the `can_skip_password_change` [permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}}). This permission is a [feature flag](/community/contributing/code/core/feature-flags) and will be removed in a later CHT release. Subsequent logins won’t require a password change – if the app closes before changing the password, the user will be prompted again when they reopen it. If a user is unable to update their password, they won’t be able to access the app. diff --git a/content/en/building/reference/api.md b/content/en/building/reference/api.md index 20cd5f2e8c..db2c713c87 100644 --- a/content/en/building/reference/api.md +++ b/content/en/building/reference/api.md @@ -2973,7 +2973,7 @@ Content-Type: application/json ## Monitoring -See the [Monitoring and alerting on the CHT](//hosting/monitoring) page for how to use this API in production. +See the [Monitoring and alerting on the CHT](/hosting/monitoring) page for how to use this API in production. ### GET /api/v1/monitoring diff --git a/content/en/building/reference/app-settings/outbound.md b/content/en/building/reference/app-settings/outbound.md index f0c8ef642b..949a0e751f 100644 --- a/content/en/building/reference/app-settings/outbound.md +++ b/content/en/building/reference/app-settings/outbound.md @@ -199,7 +199,7 @@ Example: you want the system to send outbound pushes based on a cron schedule ev #### Troubleshooting -By default, Sentinel will log a message each time an outbound request is sent indicating if the request was successful or not. If you are having trouble getting your outbound requests to work, you can [enable debug logging](//hosting/cht/docker/logs#setting-log-level) to get more information about the exact contents of the request/response. +By default, Sentinel will log a message each time an outbound request is sent indicating if the request was successful or not. If you are having trouble getting your outbound requests to work, you can [enable debug logging](/hosting/cht/docker/logs#setting-log-level) to get more information about the exact contents of the request/response. ## How Outbound messages are sent diff --git a/content/en/building/training/users-bulk-load.md b/content/en/building/training/users-bulk-load.md index e45703529c..771ae05570 100644 --- a/content/en/building/training/users-bulk-load.md +++ b/content/en/building/training/users-bulk-load.md @@ -17,7 +17,7 @@ relatedContent: > --- {{< callout >}} - The bulk user upload feature is available in 3.16.0 and later versions of the CHT. As of CHT 3.17.0, when creating both a contact and a place, the contact will be set as the default contact of the place. User creation can be scripted using the [CHT API](/building/reference/api#post-apiv2users) directly or using the [`cht-conf` tool](https://github.com/medic/cht-conf), which is detailed in the [CSV-to-Docs guide](//community/contributing/code/test-data/csv-to-docs). + The bulk user upload feature is available in 3.16.0 and later versions of the CHT. As of CHT 3.17.0, when creating both a contact and a place, the contact will be set as the default contact of the place. User creation can be scripted using the [CHT API](/building/reference/api#post-apiv2users) directly or using the [`cht-conf` tool](https://github.com/medic/cht-conf), which is detailed in the [CSV-to-Docs guide](/community/contributing/code/test-data/csv-to-docs). This feature can be used to load as many users as possible but works optimally with chunks of 1,000 users or less. {{< /callout >}} diff --git a/content/en/community/contributing/code/core/dev-environment.md b/content/en/community/contributing/code/core/dev-environment.md index ca93dd937e..1409182283 100644 --- a/content/en/community/contributing/code/core/dev-environment.md +++ b/content/en/community/contributing/code/core/dev-environment.md @@ -11,9 +11,9 @@ aliases: --- {{< callout >}} -This guide assumes you are a CHT Core developer wanting to run the CHT Core from source code to make commits to the [public GitHub repository](https://github.com/medic/cht-core). To set up your environment for developing apps, see the [app guide](//hosting/cht/app-developer.md). +This guide assumes you are a CHT Core developer wanting to run the CHT Core from source code to make commits to the [public GitHub repository](https://github.com/medic/cht-core). To set up your environment for developing apps, see the [app guide](/hosting/cht/app-developer.md). -To deploy the CHT in production, see either [hosting section](//hosting/cht). +To deploy the CHT in production, see either [hosting section](/hosting/cht). {{< /callout >}} ## The Happy Path Installation diff --git a/content/en/community/contributing/disclosing-vulnerabilities.md b/content/en/community/contributing/disclosing-vulnerabilities.md index 7ba3e3c5f8..6f8da33178 100644 --- a/content/en/community/contributing/disclosing-vulnerabilities.md +++ b/content/en/community/contributing/disclosing-vulnerabilities.md @@ -34,7 +34,7 @@ If you follow these guidelines when reporting an issue to us, we commit to: ## In Scope -A local CHT instance is included in the scope. Follow the [manual instructions](//hosting/cht/app-developer) to set up a CHT instance. +A local CHT instance is included in the scope. Follow the [manual instructions](/hosting/cht/app-developer) to set up a CHT instance. ## Out of scope diff --git a/content/en/hosting/_index.md b/content/en/hosting/_index.md index f9a0780d0f..973b2d35d4 100644 --- a/content/en/hosting/_index.md +++ b/content/en/hosting/_index.md @@ -10,9 +10,9 @@ aliases: This section has instructions on how to host the CHT Core starting with the most basic Application Development setup on your laptop for just one developer all the way up to large deployments which include multi-node CouchDB cluster hosted in a Cloud based deployment. -New developers to the CHT should start with the [Application Developer Hosting](//hosting/cht/app-developer). +New developers to the CHT should start with the [Application Developer Hosting](/hosting/cht/app-developer). -System administrators looking to deploy CHT into production should understand [the requirements to host the CHT](//hosting/cht/requirements/) first, then read the [Docker or Kubernetes](//hosting/cht/kubernetes-vs-docker/) to select a style of hosting that best fits them. +System administrators looking to deploy CHT into production should understand [the requirements to host the CHT](/hosting/cht/requirements/) first, then read the [Docker or Kubernetes](/hosting/cht/kubernetes-vs-docker/) to select a style of hosting that best fits them. {{< cards >}} {{< card link="cht/" title="CHT Core" icon="template" subtitle="Guides for hosting CHT applications" >}} diff --git a/content/en/hosting/analytics/_index.md b/content/en/hosting/analytics/_index.md index d0f02fdb13..7524cef4c0 100644 --- a/content/en/hosting/analytics/_index.md +++ b/content/en/hosting/analytics/_index.md @@ -16,6 +16,6 @@ aliases: Most CHT deployments require some sort of analytics so that stakeholders can make data driven decisions. CouchDB, which is the database used by the CHT, is not designed for analytics. It is a document database, which means that it is optimized for storing and retrieving documents, and not for aggregating data. For example, if you wanted to know how many patients were registered in a particular area, you would have to query the database for all the patients in that area, and then count them. This is not a very efficient process. It is much more efficient to store the number of patients in a particular area in a separate database, and update that number whenever a patient is registered or unregistered. This is what CHT Sync is designed to do. -[CHT Sync](/technical-overview/architecture/cht-sync) is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It has been designed to work in both local development environments for testing models or workflows, and in production environments. It can be deployed using [Docker or Kubernetes](//hosting/cht/kubernetes-vs-docker). It is supported on CHT 3.12 and later, including CHT 4.x. By using CHT Sync, a CHT deployment can easily get analytics by using a [data visualization tool](//hosting/analytics/dashboards), such as [Superset](https://superset.apache.org/). CHT Sync is open-source and has no licensing fees. +[CHT Sync](/technical-overview/architecture/cht-sync) is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It has been designed to work in both local development environments for testing models or workflows, and in production environments. It can be deployed using [Docker or Kubernetes](/hosting/cht/kubernetes-vs-docker). It is supported on CHT 3.12 and later, including CHT 4.x. By using CHT Sync, a CHT deployment can easily get analytics by using a [data visualization tool](/hosting/analytics/dashboards), such as [Superset](https://superset.apache.org/). CHT Sync is open-source and has no licensing fees. {{< subpages >}} diff --git a/content/en/hosting/analytics/building-dbt-models.md b/content/en/hosting/analytics/building-dbt-models.md index 78f4133a95..88fbc856fa 100644 --- a/content/en/hosting/analytics/building-dbt-models.md +++ b/content/en/hosting/analytics/building-dbt-models.md @@ -25,7 +25,7 @@ If using the [configurable contact hierarchy]({{< ref "building/reference/app-se ## Prerequisites -- An existing install of CHT Sync via [Docker](//hosting/analytics/setup-docker-compose) or [Kubernetes](//hosting/analytics/setup-kubernetes) +- An existing install of CHT Sync via [Docker](/hosting/analytics/setup-docker-compose) or [Kubernetes](/hosting/analytics/setup-kubernetes) - [cht-pipeline](https://github.com/medic/cht-pipeline) GitHub repository (can be cloned via `git clone https://github.com/medic/cht-pipeline`). ## Setup @@ -39,14 +39,14 @@ packages: ``` To avoid breaking changes in downstream models, include `revision` in the dependency, which should be a version tag for `cht-pipeline`. -In the CHT Sync config, set the URL of the dbt GitHub repository to the `CHT_PIPELINE_BRANCH_URL` [environment variable](//hosting/analytics/environment-variables), either in `.env` if using Docker compose, or in `values.yaml` if using Kubernetes. +In the CHT Sync config, set the URL of the dbt GitHub repository to the `CHT_PIPELINE_BRANCH_URL` [environment variable](/hosting/analytics/environment-variables), either in `.env` if using Docker compose, or in `values.yaml` if using Kubernetes. > [!IMPORTANT] > If `CHT_PIPELINE_BRANCH_URL` is pointing to a private GitHub repository, you'll need an access token in the URL. Assuming your repository is `medic/cht-pipeline`, you would replace `` with an access token: `https://@github.com/medic/cht-pipeline.git#main`. See [GitHub's instructions](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) on how to generate a token. If you create a fine-grained access token you need to provide read and write access to the [contents](https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28#repository-permissions-for-contents) of the repository. ### Local development -When creating/modifying models, you can use the Docker [local profile](//hosting/analytics/setup-docker-compose#local) to run a local test instance of CHT Sync that can reference your model configuration directly on your local machine (without needing to commit/push the changes remotely). +When creating/modifying models, you can use the Docker [local profile](/hosting/analytics/setup-docker-compose#local) to run a local test instance of CHT Sync that can reference your model configuration directly on your local machine (without needing to commit/push the changes remotely). ### Deploying models @@ -395,7 +395,7 @@ Examples of changes that are not considered breaking: - adding tests ## Database disk space requirements -The disk space required for the database depends on a few things including the size the of CouchDB databases being replicated, and the [models](//hosting/analytics/building-dbt-models) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to Postgres and then run the following command to see disk usage: +The disk space required for the database depends on a few things including the size the of CouchDB databases being replicated, and the [models](/hosting/analytics/building-dbt-models) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to Postgres and then run the following command to see disk usage: ```shell SELECT pg_size_pretty(pg_database_size('your_database_name')); ``` @@ -410,7 +410,7 @@ To get the percentage of documents that have synced you can run the following qu SELECT (COUNT(*) * 100 / (COUNT(*) + (SELECT SUM(pending) FROM v1.couchdb_progress))) AS sync_percentage FROM v1.couchdb; ``` -This query selects the total number of documents that have been synced to the `v1.couchdb` table and divides it by the total number of documents that have been synced and the number of documents that are pending to be synced. This will give you the percentage of documents that have been synced. Note that the schema and table name could differ according to the [environment variables](//hosting/analytics/environment-variables) you set so update them accordingly. Run this query periodically to monitor the progress of the sync and stop the sync process once you get to the desired percentage. It's okay if it is not exactly 10% as long as it is close enough to give you an idea of the disk space required. +This query selects the total number of documents that have been synced to the `v1.couchdb` table and divides it by the total number of documents that have been synced and the number of documents that are pending to be synced. This will give you the percentage of documents that have been synced. Note that the schema and table name could differ according to the [environment variables](/hosting/analytics/environment-variables) you set so update them accordingly. Run this query periodically to monitor the progress of the sync and stop the sync process once you get to the desired percentage. It's okay if it is not exactly 10% as long as it is close enough to give you an idea of the disk space required. You can then multiply this figure by 10 to get an estimate of the disk space required for the full dataset and then add some extra space for indexes and other overhead as well as future growth. diff --git a/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md b/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md index 25ad9365ee..3025e05f4d 100644 --- a/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md +++ b/content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md @@ -12,22 +12,22 @@ aliases: - /building/guides/data/analytics/couch2pg-to-cht-sync-migration --- -This page outlines guidelines for migrating from [couch2pg](https://github.com/medic/cht-couch2pg) to the data pipeline based on [CHT Sync](https://github.com/medic/cht-sync). One of the main changes in this flow is separating the syncing process from the data transformation, with dbt now handling the latter in [cht-pipeline](https://github.com/medic/cht-pipeline/). This migration requires dbt models in the cht-pipeline repository instead of SQL views and tables. One thing to note is that the schema for CHT Sync differs from cht-couch2pg, so dbt models will not directly replace the SQL views and tables. For instructions on how to get started with dbt models, refer to the [dbt models guide](//hosting/analytics/testing-dbt-models). +This page outlines guidelines for migrating from [couch2pg](https://github.com/medic/cht-couch2pg) to the data pipeline based on [CHT Sync](https://github.com/medic/cht-sync). One of the main changes in this flow is separating the syncing process from the data transformation, with dbt now handling the latter in [cht-pipeline](https://github.com/medic/cht-pipeline/). This migration requires dbt models in the cht-pipeline repository instead of SQL views and tables. One thing to note is that the schema for CHT Sync differs from cht-couch2pg, so dbt models will not directly replace the SQL views and tables. For instructions on how to get started with dbt models, refer to the [dbt models guide](/hosting/analytics/testing-dbt-models). ## Key Considerations -- **Kubernetes vs Docker Compose**: CHT Sync provides configurations to support deployment to test and production environments with Docker Compose or Kubernetes. You can read more about the CHT hosting options in the [dedicated page](//hosting/cht/kubernetes-vs-docker). -- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources](//hosting/analytics/building-dbt-models#database-disk-space-requirements) are sufficient to handle the load. +- **Kubernetes vs Docker Compose**: CHT Sync provides configurations to support deployment to test and production environments with Docker Compose or Kubernetes. You can read more about the CHT hosting options in the [dedicated page](/hosting/cht/kubernetes-vs-docker). +- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources](/hosting/analytics/building-dbt-models#database-disk-space-requirements) are sufficient to handle the load. - **dbt modelling**: Avoid the temptation to model new dbt models after existing SQL views and tables. Instead, take the opportunity to re-evaluate the data needs and design new models that are more efficient and effective. Think of what data needs to be shown and how it should be shown in data visualization tools and use that to guide the design of the new models. -- **Testing**: After migrating, thoroughly test the new dbt models to ensure that they work as expected. Refer to the [testing dbt models guide](//hosting/analytics/building-dbt-models) for guidelines on testing. +- **Testing**: After migrating, thoroughly test the new dbt models to ensure that they work as expected. Refer to the [testing dbt models guide](/hosting/analytics/building-dbt-models) for guidelines on testing. - **Feedback**: Provide any feedback and create issues for errors or bugs encountered in the [cht-sync](https://github.com/medic/cht-sync) and [cht-pipeline](https://github.com/medic/cht-pipeline/) repositories to improve the tools. ## Migration Steps 1. **Plan the migration**: Determine the scope of the migration, including the data sources, the data models, and the data transformations. Identify the existing SQL views, tables, and dashboards and assess what data you want to visualize. -1. **Set up CHT Sync**: Follow the instructions to setup CHT Sync with [Docker Compose](//hosting/analytics/setup-docker-compose) or [Kubernetes](//hosting/analytics/setup-kubernetes) -1. **Build dbt models**: Use the [dedicated guidelines](//hosting/analytics/building-dbt-models) to build dbt models for the data you want to visualize. +1. **Set up CHT Sync**: Follow the instructions to setup CHT Sync with [Docker Compose](/hosting/analytics/setup-docker-compose) or [Kubernetes](/hosting/analytics/setup-kubernetes) +1. **Build dbt models**: Use the [dedicated guidelines](/hosting/analytics/building-dbt-models) to build dbt models for the data you want to visualize. 1. **Deploy CHT Sync**: Once the dbt models are tested locally or in a test environment and working as expected, deploy CHT Sync in a production environment. It is recommended that CHT Sync be run in parallel with couch2pg during the migration process. This minimises disruption to users of the existing dashboards because they can continue to use the existing data while the new pipeline is being set up. It also makes it easier to compare the data from couch2pg when testing the new pipeline. 1. **Create replica dashboards**: In the data visualization tool of your choice, create replica dashboards of your current setup and compare the data from the old and new pipelines. 1. **Test and adjust the dbt models**: Test the dbt models to ensure they are working as expected and that the replica and initial dashboards match. Adjust the models to ensure they are accurate. -1. **Optimize**: Once the dbt models are working as expected and the dashboards display the expected data, optimize the models to improve performance. This may involve restructuring the models, adding indexes, or making other adjustments to improve the speed and efficiency of the models. Having a look at the [dbt models guide](//hosting/analytics/building-dbt-models) will help you understand how to optimize the models. -1. **Set up monitoring and alerting**: [Set up CHT Watchdog](//hosting/monitoring/setup) to monitor the running of CHT Sync and set up alerts for any failures. +1. **Optimize**: Once the dbt models are working as expected and the dashboards display the expected data, optimize the models to improve performance. This may involve restructuring the models, adding indexes, or making other adjustments to improve the speed and efficiency of the models. Having a look at the [dbt models guide](/hosting/analytics/building-dbt-models) will help you understand how to optimize the models. +1. **Set up monitoring and alerting**: [Set up CHT Watchdog](/hosting/monitoring/setup) to monitor the running of CHT Sync and set up alerts for any failures. 1. **Remove couch2pg and the duplicate database**: Once the new pipeline runs as expected, you can remove couch2pg and the duplicate database. Ensure that all data is being synced correctly, that the dbt models are working as expected, and that the dashboards display the expected data before switching them off and removing couch2pg. diff --git a/content/en/hosting/analytics/dashboards.md b/content/en/hosting/analytics/dashboards.md index cf12e8c530..24d5bc997d 100644 --- a/content/en/hosting/analytics/dashboards.md +++ b/content/en/hosting/analytics/dashboards.md @@ -10,7 +10,7 @@ relatedContent: > --- {{< callout >}} - These instructions assume you are running CHT Sync, CHT Core and PostgreSQL either with [Kubernetes](//hosting/analytics/setup-kubernetes) or [Docker](//hosting/analytics/setup-docker-compose). + These instructions assume you are running CHT Sync, CHT Core and PostgreSQL either with [Kubernetes](/hosting/analytics/setup-kubernetes) or [Docker](/hosting/analytics/setup-docker-compose). {{< /callout >}} ## Superset diff --git a/content/en/hosting/analytics/environment-variables.md b/content/en/hosting/analytics/environment-variables.md index 18f811b507..67673894dc 100644 --- a/content/en/hosting/analytics/environment-variables.md +++ b/content/en/hosting/analytics/environment-variables.md @@ -32,8 +32,8 @@ There are three groups of environment variables. One for Postgres, one for Couch | `COUCHDB_HOST` | `couchdb` | Host of the CouchDB instance | | `COUCHDB_PORT` | `5984` | Port of the CouchDB instance | | `COUCHDB_SECURE` | `false` | Does the connection to CouchDB use HTTPS? | -| `DBT_THREAD_COUNT` | 1 | [Number of threads](//hosting/analytics/tuning-dbt#threads) per DBT process | -| `DBT_BATCH_SIZE` | 0 | [Batch size](//hosting/analytics/tuning-dbt#batching) for batched incremental runs | +| `DBT_THREAD_COUNT` | 1 | [Number of threads](/hosting/analytics/tuning-dbt#threads) per DBT process | +| `DBT_BATCH_SIZE` | 0 | [Batch size](/hosting/analytics/tuning-dbt#batching) for batched incremental runs | | `DBT_LOCAL_PATH` | | When running DBT locally for development, the path to the models directory on the host | -| `DBT_SELECTOR` | '' | If using separate DBT processes, the [select condition](//hosting/analytics/tuning-dbt#multiple-dbt-containers) to select a subset of the models for a single dbt process. | +| `DBT_SELECTOR` | '' | If using separate DBT processes, the [select condition](/hosting/analytics/tuning-dbt#multiple-dbt-containers) to select a subset of the models for a single dbt process. | diff --git a/content/en/hosting/analytics/setup-docker-compose.md b/content/en/hosting/analytics/setup-docker-compose.md index 9fd81e9c7d..b409809a89 100644 --- a/content/en/hosting/analytics/setup-docker-compose.md +++ b/content/en/hosting/analytics/setup-docker-compose.md @@ -12,20 +12,20 @@ aliases: - /building/guides/data/analytics/setup --- -This guide will walk you through setting up a deployment of CHT Sync with the CHT using Docker. This path is recommended if you host the [CHT with Docker](//hosting/cht/docker). +This guide will walk you through setting up a deployment of CHT Sync with the CHT using Docker. This path is recommended if you host the [CHT with Docker](/hosting/cht/docker). ## Prerequisites - [Current version](https://docs.docker.com/engine/install/) of `docker` or current version of [Docker Desktop](https://www.docker.com/products/docker-desktop/) both of which include `docker compose`. Note that the older `docker-compose` is [no longer supported](https://www.docker.com/blog/announcing-compose-v2-general-availability/). - [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - [cht-sync](https://github.com/medic/cht-sync) GitHub repository (can be cloned via `git clone https://github.com/medic/cht-sync`). -- [A dbt project](//hosting/analytics/building-dbt-models). +- [A dbt project](/hosting/analytics/building-dbt-models). ## Setup -In the `cht-sync` folder, copy the values from the `env.template` file to a `.env` file. For more information, see the references on the [Environment variables page](//hosting/analytics/environment-variables). +In the `cht-sync` folder, copy the values from the `env.template` file to a `.env` file. For more information, see the references on the [Environment variables page](/hosting/analytics/environment-variables). -Configure the `COUCHDB_*` environment variables to connect to your CouchDB instance. For production CHT Core deployments, the port will most likely need to be set to `443` like this: `COUCHDB_PORT=443`. This is because CHT Core uses an `nginx` [reverse proxy](/technical-overview/architecture#overview) on port `443`, instead of the default `5984` port used in a stand-alone CouchDB instance which the `env.template` [has](//hosting/analytics/environment-variables). +Configure the `COUCHDB_*` environment variables to connect to your CouchDB instance. For production CHT Core deployments, the port will most likely need to be set to `443` like this: `COUCHDB_PORT=443`. This is because CHT Core uses an `nginx` [reverse proxy](/technical-overview/architecture#overview) on port `443`, instead of the default `5984` port used in a stand-alone CouchDB instance which the `env.template` [has](/hosting/analytics/environment-variables). > [!IMPORTANT] > The first time you run the commands from any of the sections below it will need to download many Docker images and will take a while. You'll know it's done when you see `#8 DONE 0.0s` and you are returned to the command line. Be patient! @@ -43,7 +43,7 @@ The following profiles are available: This setup involves starting couch2pg, PostgreSQL, pgAdmin and dbt. It assumes you have a CouchDB instance running, and you updated the `.env` CouchDB variables accordingly. -The dbt container needs a project to run. To develop and test models locally, [set up a dbt project](//hosting/analytics/building-dbt-models#setup) and set the path to the project to the `DBT_LOCAL_PATH` [environment variable](//hosting/analytics/environment-variables) in `.env`. You must set this to a valid directory where you have your CHT Pipeline models. You can not use `--local` profile without setting this. +The dbt container needs a project to run. To develop and test models locally, [set up a dbt project](/hosting/analytics/building-dbt-models#setup) and set the path to the project to the `DBT_LOCAL_PATH` [environment variable](/hosting/analytics/environment-variables) in `.env`. You must set this to a valid directory where you have your CHT Pipeline models. You can not use `--local` profile without setting this. When running, the dbt container then will use the local models in the path specified in `DBT_LOCAL_PATH` with out needing to query a remote git repository. @@ -68,7 +68,7 @@ The dbt container will run the models in the path specified in `DBT_LOCAL_PATH`. #### Production -This setup involves starting couch2pg and one dbt container. It assumes you have an external CouchDB instance and Postgres DB. The credentials and settings for these databases are configured in [.env](//hosting/analytics/environment-variables). +This setup involves starting couch2pg and one dbt container. It assumes you have an external CouchDB instance and Postgres DB. The credentials and settings for these databases are configured in [.env](/hosting/analytics/environment-variables). Run the Docker containers with profile `production` and wait for every container to be up and running: ```sh @@ -79,7 +79,7 @@ You can verify this command worked by running `docker ps`. It should show three ### Tuning dbt -In production setups with large tables, it can be helpful to [tune how dbt runs](//hosting/analytics/tuning-dbt). +In production setups with large tables, it can be helpful to [tune how dbt runs](/hosting/analytics/tuning-dbt). To use threads or batching, set the corresponding environment variables in `.env`. ```conf @@ -178,4 +178,4 @@ To add these columns log in to the database and run this sql. In V2, the commands for running CHT sync have changed; a profile is required as described above. When testinging locally and using the `local` profile, the environment variable `DBT_LOCAL_PATH` must be set. -V2 adds new features for [tuning dbt](//hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](//hosting/analytics/environment-variables) in `.env` as described above. +V2 adds new features for [tuning dbt](/hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](/hosting/analytics/environment-variables) in `.env` as described above. diff --git a/content/en/hosting/analytics/setup-kubernetes.md b/content/en/hosting/analytics/setup-kubernetes.md index 7bd6621321..333af49e3e 100644 --- a/content/en/hosting/analytics/setup-kubernetes.md +++ b/content/en/hosting/analytics/setup-kubernetes.md @@ -12,7 +12,7 @@ aliases: - /building/guides/data/analytics/production --- -This guide will walk you through setting up a deployment of CHT Sync with the CHT using Kubernetes. This path is recommended if you already have a Kubernetes cluster [hosting the CHT](//hosting/cht/kubernetes). +This guide will walk you through setting up a deployment of CHT Sync with the CHT using Kubernetes. This path is recommended if you already have a Kubernetes cluster [hosting the CHT](/hosting/cht/kubernetes). ## Prerequisites @@ -87,13 +87,13 @@ If an instance has a different port, user or different CouchDB databases to be s password: "password3" ``` -Set the [cht-pipeline branch URL](//hosting/analytics/building-dbt-models#setup) in the `values.yaml` file. +Set the [cht-pipeline branch URL](/hosting/analytics/building-dbt-models#setup) in the `values.yaml` file. ```yaml cht_pipeline_branch_url: "https://github.com/medic/cht-pipeline.git#main" ``` -(Optional) You can also configure a Metrics Exporter. If enabled, this will create a sql exporter that queries the database for couch2pg status, number of changes pending, and current sequence and exposes these metrics in Prometheus format at a service with name `metrics` at port 9399, for use with [CHT Watchdog](//hosting/monitoring/setup) or any other monitoring service. +(Optional) You can also configure a Metrics Exporter. If enabled, this will create a sql exporter that queries the database for couch2pg status, number of changes pending, and current sequence and exposes these metrics in Prometheus format at a service with name `metrics` at port 9399, for use with [CHT Watchdog](/hosting/monitoring/setup) or any other monitoring service. An HTTP ingress needs to be created to allow access from outside the cluster. @@ -126,7 +126,7 @@ kubectl logs -f cht-sync- ### Tuning dbt -In production setups with large tables, it can be helpful to [tune how dbt runs](//hosting/analytics/tuning-dbt). +In production setups with large tables, it can be helpful to [tune how dbt runs](/hosting/analytics/tuning-dbt). To use threads or batching, set the corresponding values in the `values.yaml` file. ```yaml @@ -168,4 +168,4 @@ To add these columns log in to the database and run this sql. CREATE INDEX IF NOT EXISTS source ON couchdb(source); ``` -V2 adds new features for [tuning dbt](//hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](//hosting/analytics/environment-variables) in `values.yml` as described above. +V2 adds new features for [tuning dbt](/hosting/analytics/tuning-dbt); to use batching, threads, or separate dbt processes, set the corresponding [environment_variables](/hosting/analytics/environment-variables) in `values.yml` as described above. diff --git a/content/en/hosting/analytics/tuning-dbt.md b/content/en/hosting/analytics/tuning-dbt.md index 49d4a15c34..038ce204de 100644 --- a/content/en/hosting/analytics/tuning-dbt.md +++ b/content/en/hosting/analytics/tuning-dbt.md @@ -39,10 +39,10 @@ Each dbt container is passed an environment variable `DBT_SELECTOR` that is used One dbt container should be set up to run the base models. This can be done by using the selector `package:cht_pipeline_base` or, to separate telemetry models from base models, use `tag:base` and `tag:users`. -To run custom models in separate containers, either use a package select with your dbt package name (`package:[YOUR_PACKAGE_NAME]`), or for more fine-grained control, add [tags](//hosting/analytics/tuning-dbt#dbt-tags) to your models and use tag selectors (`tag:[YOUR_TAG]`). +To run custom models in separate containers, either use a package select with your dbt package name (`package:[YOUR_PACKAGE_NAME]`), or for more fine-grained control, add [tags](/hosting/analytics/tuning-dbt#dbt-tags) to your models and use tag selectors (`tag:[YOUR_TAG]`). Although it is possible to use any condition, using tags is the simplest way to separate models. -How to configure the different dbt containers to use these selectors depends on whether CHT Sync is running in [docker-compose](//hosting/analytics/setup-docker-compose#tuning-dbt) or [kubernetes](//hosting/analytics/setup-kubernetes#tuning-dbt). +How to configure the different dbt containers to use these selectors depends on whether CHT Sync is running in [docker-compose](/hosting/analytics/setup-docker-compose#tuning-dbt) or [kubernetes](/hosting/analytics/setup-kubernetes#tuning-dbt). In Kubernetes, add the selectors to the `values.yaml` file as a list called `dbt_selectors` ```yaml diff --git a/content/en/hosting/cht/_index.md b/content/en/hosting/cht/_index.md index d518496778..e02c8d8299 100644 --- a/content/en/hosting/cht/_index.md +++ b/content/en/hosting/cht/_index.md @@ -13,9 +13,9 @@ aliases: > [!TIP] > To get an overview on how these hosting solutions use `docker` and other key CHT concepts, be sure to read the [guide on a Local Setup](/building/local-setup). -Before beginning any of these guides, be sure to meet all of the [CHT hosting requirements](//hosting/cht/requirements) first. For example, [backups](/hosting/cht/docker/backups) are required for any successful CHT deployment. +Before beginning any of these guides, be sure to meet all of the [CHT hosting requirements](/hosting/cht/requirements) first. For example, [backups](/hosting/cht/docker/backups) are required for any successful CHT deployment. -To host a production instance of CHT, use the [Production Hosting in CHT](//hosting/cht/docker) guide. To do app development, see our [App Developer](//hosting/cht/app-developer) hosting guide. +To host a production instance of CHT, use the [Production Hosting in CHT](/hosting/cht/docker) guide. To do app development, see our [App Developer](/hosting/cht/app-developer) hosting guide. {{< cards >}} {{< card link="considerations" title="Considerations" subtitle="Considerations when hosting the CHT" icon="book-open" >}} diff --git a/content/en/hosting/cht/app-developer.md b/content/en/hosting/cht/app-developer.md index 5b70f6b892..f282b84cca 100644 --- a/content/en/hosting/cht/app-developer.md +++ b/content/en/hosting/cht/app-developer.md @@ -14,7 +14,7 @@ aliases: {{< callout >}} This guide assumes you are a CHT app developer wanting to either run concurrent instances of the CHT, or easily be able to switch between different instances without losing any data while doing so. To do development on the CHT Core Framework itself, see the [development guide](/community/contributing/code/core/dev-environment). -To deploy the CHT in production, see see the [production](//hosting/cht/docker) documentation. +To deploy the CHT in production, see see the [production](/hosting/cht/docker) documentation. {{< /callout >}} ## Getting started @@ -39,7 +39,7 @@ This script brings a lot of benefits with it: ### Installing To get started using it: -1. Meet all [CHT hosting requirements](//hosting/cht/requirements) +1. Meet all [CHT hosting requirements](/hosting/cht/requirements) 2. Clone the [CHT Core](https://github.com/medic/cht-core/) repo 3. When you want to check for updates, just run `git pull origin` in the `cht-core` directory. @@ -196,7 +196,7 @@ Here is a video of the helper being run on 1 Dec 2022. The video references `laz ## Manual `docker compose` method -This process achieves the same result as Docker Helper, but is a more manual process. Be sure the [CHT hosting requirements](//hosting/cht/requirements) are all met first. +This process achieves the same result as Docker Helper, but is a more manual process. Be sure the [CHT hosting requirements](/hosting/cht/requirements) are all met first. To avoid conflicts, ensure that all other CHT 4.x instances are stopped. To stop ALL containers, you can use diff --git a/content/en/hosting/cht/considerations.md b/content/en/hosting/cht/considerations.md index ff91ad0284..08c68d4475 100644 --- a/content/en/hosting/cht/considerations.md +++ b/content/en/hosting/cht/considerations.md @@ -10,9 +10,9 @@ aliases: --- Some important questions to consider when setting up hosting for the CHT: -* **Alerting** - How will alerts be sent in the case of downtime or degraded service? While [Watchdog](//hosting/monitoring/introduction) can be set up to monitor CHT Core instances - which monitoring system will be used to alert on OS level warnings? +* **Alerting** - How will alerts be sent in the case of downtime or degraded service? While [Watchdog](/hosting/monitoring/introduction) can be set up to monitor CHT Core instances - which monitoring system will be used to alert on OS level warnings? * **Power failures and unplanned restarts** - Will the server cleanly restart such that the CHT resumes service correctly? -* **Backups** - What happens to the CHT data if there's a hard drive failure? Are there provisions for a [3-2-1 backup strategy](https://en.wikipedia.org/wiki/Backup#Storage)? See the [backup docs](//hosting/cht/docker/backups) for more information. +* **Backups** - What happens to the CHT data if there's a hard drive failure? Are there provisions for a [3-2-1 backup strategy](https://en.wikipedia.org/wiki/Backup#Storage)? See the [backup docs](/hosting/cht/docker/backups) for more information. * **Disaster Recovery** - What happens if there is a flood at the facility and on-site active and backup data are destroyed? * **Scale** - What happens when the hardware deployed needs to be upgraded to increase capacity? * **Updates** - CHT Core updates happen many times throughout the year - do you have a maintenance schedule for these and staff who are trained to do the upgrade? diff --git a/content/en/hosting/cht/docker/_index.md b/content/en/hosting/cht/docker/_index.md index 8b416f0dcd..b9058431f0 100644 --- a/content/en/hosting/cht/docker/_index.md +++ b/content/en/hosting/cht/docker/_index.md @@ -8,7 +8,7 @@ aliases: --- {{< callout >}} -Read the [Docker vs Kubernetes](//hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. +Read the [Docker vs Kubernetes](/hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. {{< /callout >}} {{< cards >}} diff --git a/content/en/hosting/cht/docker/adding-tls-certificates.md b/content/en/hosting/cht/docker/adding-tls-certificates.md index 1fa9eb6f22..a48eb27805 100644 --- a/content/en/hosting/cht/docker/adding-tls-certificates.md +++ b/content/en/hosting/cht/docker/adding-tls-certificates.md @@ -13,7 +13,7 @@ aliases: By default, CHT will create a self-signed certificate for every deployment. These instructions are for changing to either a pre-existing certificate or automatically creating and renewing a [Certbot](https://certbot.eff.org/) based certificate using [ACME](https://acmeclients.com/), like [Let's Encrypt](https://letsencrypt.org/). -This guide assumes you've already met the [hosting requirements](//hosting/cht/requirements), specifically around Docker being installed. +This guide assumes you've already met the [hosting requirements](/hosting/cht/requirements), specifically around Docker being installed. ## Pre-existing certificate diff --git a/content/en/hosting/cht/docker/backups.md b/content/en/hosting/cht/docker/backups.md index 2a36557708..75ddc1029f 100644 --- a/content/en/hosting/cht/docker/backups.md +++ b/content/en/hosting/cht/docker/backups.md @@ -35,7 +35,7 @@ Therefore, you do **not** need to back up the docker images for: ## Assumptions -This guide assumes you have an Ubuntu server running CHT 4.x in Docker as described in our [Self Hosting in CHT 4.x - Single CouchDB Node](//hosting/cht/docker) guide. If you run `docker ps --format '{{.Names}}'` you should see something like this: +This guide assumes you have an Ubuntu server running CHT 4.x in Docker as described in our [Self Hosting in CHT 4.x - Single CouchDB Node](/hosting/cht/docker) guide. If you run `docker ps --format '{{.Names}}'` you should see something like this: ``` cht_nginx_1 diff --git a/content/en/hosting/cht/docker/installation.md b/content/en/hosting/cht/docker/installation.md index 7a99851d0e..2c68bde775 100644 --- a/content/en/hosting/cht/docker/installation.md +++ b/content/en/hosting/cht/docker/installation.md @@ -17,7 +17,7 @@ aliases: ## Prerequisites -Be sure you have followed [the requirements document](//hosting/cht/requirements) including installing Docker. This guide assumes you're using the `ubuntu` user and that it [has `sudo-less` access to Docker](https://askubuntu.com/a/477554). +Be sure you have followed [the requirements document](/hosting/cht/requirements) including installing Docker. This guide assumes you're using the `ubuntu` user and that it [has `sudo-less` access to Docker](https://askubuntu.com/a/477554). ## Directory Structure @@ -89,7 +89,7 @@ Note that secure passwords and UUIDs were generated on the first four calls and ## Launch containers > [!IMPORTANT] -> This section has the first use of `docker compose`. If you get an error calling this, double check [hosting requirements](//hosting/cht/requirements). +> This section has the first use of `docker compose`. If you get an error calling this, double check [hosting requirements](/hosting/cht/requirements). To start your CHT instance, run the following @@ -138,7 +138,7 @@ grep COUCHDB_PASSWORD /home/ubuntu/cht/upgrade-service/.env | cut -d'=' -f2 ## TLS Certificates -See the [TLS Certificates page](//hosting/cht/docker/adding-tls-certificates) for how to import your certificates. +See the [TLS Certificates page](/hosting/cht/docker/adding-tls-certificates) for how to import your certificates. ## Upgrades diff --git a/content/en/hosting/cht/kubernetes-vs-docker.md b/content/en/hosting/cht/kubernetes-vs-docker.md index e6516d82a4..9b2da0245e 100644 --- a/content/en/hosting/cht/kubernetes-vs-docker.md +++ b/content/en/hosting/cht/kubernetes-vs-docker.md @@ -12,7 +12,7 @@ aliases: To deploy the CHT, you should use the technology you are most familiar and comfortable with. It is possible to deploy 20 CHT instances without using Kubernetes. Conversely, if a hosting organisation uses Kubernetes and intends to deploy a single instance of the CHT, that's also fine. > [!TIP] -> [Application development](//hosting/cht/app-developer) is more straightforward to setup with Docker. +> [Application development](/hosting/cht/app-developer) is more straightforward to setup with Docker. ## Which one to choose? diff --git a/content/en/hosting/cht/kubernetes/_index.md b/content/en/hosting/cht/kubernetes/_index.md index 04ad48284e..ef8c70df87 100644 --- a/content/en/hosting/cht/kubernetes/_index.md +++ b/content/en/hosting/cht/kubernetes/_index.md @@ -8,7 +8,7 @@ aliases: --- {{< callout >}} -Read the [Docker vs Kubernetes](//hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. +Read the [Docker vs Kubernetes](/hosting/cht/kubernetes-vs-docker/) documentation to select a style of hosting that best fits your CHT deployment. {{< /callout >}} {{< subpages >}} diff --git a/content/en/hosting/cht/requirements.md b/content/en/hosting/cht/requirements.md index c96c72d5a7..b5aa626698 100644 --- a/content/en/hosting/cht/requirements.md +++ b/content/en/hosting/cht/requirements.md @@ -15,7 +15,7 @@ aliases: For production CHT deployments, Linux is recommended, with [Ubuntu](https://ubuntu.com/server) the most commonly used. For App Developer Hosting, Linux or macOS may be used. Windows can be used for either, but without recommendation. {{< /callout >}} -Per the [Kubernetes vs Docker](//hosting/cht/kubernetes-vs-docker) page, CHT Core can be deployed with either Docker or Kubernetes. +Per the [Kubernetes vs Docker](/hosting/cht/kubernetes-vs-docker) page, CHT Core can be deployed with either Docker or Kubernetes. ## App Developer Hosting @@ -23,7 +23,7 @@ This leverages Docker and requires: * 4 GB RAM / 2 CPU / 8 GB SSD * Root Access -* TLS certificates - if using [Docker Helper](//hosting/cht/app-developer#cht-docker-helper-for-4x) these are provided for you. +* TLS certificates - if using [Docker Helper](/hosting/cht/app-developer#cht-docker-helper-for-4x) these are provided for you. * [Current version](https://docs.docker.com/engine/install/) of `docker` or current version of [Docker Desktop](https://www.docker.com/products/docker-desktop/) both of which include `docker compose`. Note that the older `docker-compose` is [no longer supported](https://www.docker.com/blog/announcing-compose-v2-general-availability/). ## Production Hosting @@ -37,7 +37,7 @@ This leverages Docker and requires: ### Kubernetes -This guide refers to "Kubernetes", and a lightweight orchestrator called [K3s](https://docs.k3s.io/) can be used for bare-metal hosts. The requirements below refer to K3s deployments but can be translated to other Kubernetes hosting. For example, for cloud hosting, CHT is widely deployed with Amazon [Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS). Additionally, the CHT is succesfully deployed in a [large K3s deployment based on VMWare](//hosting/cht/kubernetes/self-hosting-k3s-multinode). +This guide refers to "Kubernetes", and a lightweight orchestrator called [K3s](https://docs.k3s.io/) can be used for bare-metal hosts. The requirements below refer to K3s deployments but can be translated to other Kubernetes hosting. For example, for cloud hosting, CHT is widely deployed with Amazon [Elastic Kubernetes Service](https://aws.amazon.com/eks/) (EKS). Additionally, the CHT is succesfully deployed in a [large K3s deployment based on VMWare](/hosting/cht/kubernetes/self-hosting-k3s-multinode). Be sure to see the `cht-deploy` [script](https://github.com/medic/cht-core/tree/master/scripts/deploy) that leverage the `helm` [application](https://helm.sh/docs/intro/install/). diff --git a/content/en/hosting/cht/upgrade-troubleshooting.md b/content/en/hosting/cht/upgrade-troubleshooting.md index 8711c584ee..c9a777183b 100644 --- a/content/en/hosting/cht/upgrade-troubleshooting.md +++ b/content/en/hosting/cht/upgrade-troubleshooting.md @@ -17,7 +17,7 @@ aliases: There's a concept of upgrades "getting stuck" which mainly means that after many many hours an upgrade is not making any progress. Most likely, this will manifest as the progress bars in the upgrade admin web UI not increasing and "sticking" at a certain percentage. An alternate possibility is that the progress bars disappear altogether. > [!WARNING] -> All tips apply to both [Docker](//hosting/cht/docker) and [Kubernetes](//hosting/cht/kubernetes) based deployments unless otherwise specified. +> All tips apply to both [Docker](/hosting/cht/docker) and [Kubernetes](/hosting/cht/kubernetes) based deployments unless otherwise specified. > All upgrades are expected to succeed without issue. Do not attempt any fixes unless you actively have a problem upgrading. ## Considerations diff --git a/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md b/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md index 3b4e586c12..549015567a 100644 --- a/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md +++ b/content/en/hosting/medic/data-migration-3x-eks-to-4x-eks.md @@ -9,7 +9,7 @@ aliases: - /contribute/medic/data-migration-3x-eks-to-4x-eks --- -Like the [Deploy to EKS guide](//hosting/medic/deploy-on-eks), this guide is meant for Medic Teammates migrating Medic hosted CHT Core deployments. However, given there may be other users who will benefit from understanding the process, this document is published for all to read. +Like the [Deploy to EKS guide](/hosting/medic/deploy-on-eks), this guide is meant for Medic Teammates migrating Medic hosted CHT Core deployments. However, given there may be other users who will benefit from understanding the process, this document is published for all to read. CHT Core hosting architecture differs entirely between 3.x and 4.x. When both versions are running in Kubernetes, migrating data requires specific steps using the [couchdb-migration](https://github.com/medic/couchdb-migration) tool. This tool interfaces with CouchDB to update shard maps and database metadata. diff --git a/content/en/hosting/monitoring/integration.md b/content/en/hosting/monitoring/integration.md index dab3d2ee16..0cbd6e4ed1 100644 --- a/content/en/hosting/monitoring/integration.md +++ b/content/en/hosting/monitoring/integration.md @@ -10,7 +10,7 @@ aliases: ## Going beyond basic setup -After you have done the [setup of CHT Watchdog](//hosting/monitoring/setup.md) and configured it to run [with TLS and have backups enabled](//hosting/monitoring/production.md), you may want to extend it to scrape other Prometheus data sources so that Grafana can send alerts on non-CHT Core metrics. +After you have done the [setup of CHT Watchdog](/hosting/monitoring/setup.md) and configured it to run [with TLS and have backups enabled](/hosting/monitoring/production.md), you may want to extend it to scrape other Prometheus data sources so that Grafana can send alerts on non-CHT Core metrics. This guide uses example instances of CHT Core (`cht.example.com`) and CHT Watchdog (`watchdog.example.com`). When deploying, be sure to replace with your own hostnames. @@ -111,7 +111,7 @@ services: #### Caddy Config and Compose files -Like we did in the [TLS section](//hosting/monitoring/production#accessing-grafana-over-tls), we'll add both a `/home/ubuntu/Caddyfile` and a `/home/ubuntu/cht/compose/caddy-compose.yml`. +Like we did in the [TLS section](/hosting/monitoring/production#accessing-grafana-over-tls), we'll add both a `/home/ubuntu/Caddyfile` and a `/home/ubuntu/cht/compose/caddy-compose.yml`. Starting with the `Caddyfile`, let's assume your server's DNS entry is `cht.example.com`. We can expose cAdvisor's service running on localhost port `8443` with this compose file. This tells Caddy to reverse proxy requests to the public interface to the private Docker network interface on port `8080` where cAdvisor is running: @@ -140,7 +140,7 @@ services: Now that we have all the config files in place, you need to have Docker start everything together. This is so that the containers can see each other on the same `CHT Net` Docker network. You will need to specify each of the compose files every time you start, stop or restart CHT instance so all the services stay running and connected. -Assuming you followed the [production steps](//hosting/cht/docker) to install the CHT, you use this Compose call to first stop all containers and then start them all up, including the new services: +Assuming you followed the [production steps](/hosting/cht/docker) to install the CHT, you use this Compose call to first stop all containers and then start them all up, including the new services: ```shell cd /home/ubuntu/cht/upgrade-service @@ -176,7 +176,7 @@ services: #### Load new Compose files with existing ones -Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](//hosting/monitoring/setup), this would be: +Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](/hosting/monitoring/setup), this would be: ```shell cd ~/cht-monitoring diff --git a/content/en/hosting/monitoring/introduction.md b/content/en/hosting/monitoring/introduction.md index fcd221910f..6512dcfd0f 100644 --- a/content/en/hosting/monitoring/introduction.md +++ b/content/en/hosting/monitoring/introduction.md @@ -10,7 +10,7 @@ aliases: --- {{< callout >}} -Be sure to see how to deploy a solution to [monitor and alert on production CHT instances](//hosting/monitoring/setup.md). +Be sure to see how to deploy a solution to [monitor and alert on production CHT instances](/hosting/monitoring/setup.md). {{< /callout >}} Each deployment will experience different stresses on its resources. Be sure to tune any alerting levels in the case of a false positive so that you may avoid them in the future. Any thresholds for alerts, and even what is alerted on, is just a guideline, not a guarantee of uptime. diff --git a/content/en/hosting/monitoring/postgres-ingest.md b/content/en/hosting/monitoring/postgres-ingest.md index 226d76085c..299d4f0b7e 100644 --- a/content/en/hosting/monitoring/postgres-ingest.md +++ b/content/en/hosting/monitoring/postgres-ingest.md @@ -10,7 +10,7 @@ aliases: ## Introduction -After [setting up](//hosting/monitoring/setup.md) your Watchdog instance and [making it production ready](//hosting/monitoring/production.md), you can include additional custom metrics from your deployment. These metrics should be ingested by Prometheus and then can be used to create new Grafana dashboards and alerts. Example use cases include monitoring and alerting on health metrics like CHW visits per county or household registration rates, etc. +After [setting up](/hosting/monitoring/setup.md) your Watchdog instance and [making it production ready](/hosting/monitoring/production.md), you can include additional custom metrics from your deployment. These metrics should be ingested by Prometheus and then can be used to create new Grafana dashboards and alerts. Example use cases include monitoring and alerting on health metrics like CHW visits per county or household registration rates, etc. This guide will walk you through adding a custom metric from Postgres _data_. The following naming convention is used throughout to reference the relevant server instances: CHT Core (`cht.example.com`), CHT Watchdog (`watchdog.example.com`) and a Postgres server (`db.example.com`). @@ -152,7 +152,7 @@ services: Launch Watchdog with the new compose file -Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](//hosting/monitoring/setup), this would be: +Now that you've added the new configuration files, we can load it alongside the existing ones. Assuming you've followed the [Watchdog Setup](/hosting/monitoring/setup), this would be: ```shell cd ~/cht-watchdog diff --git a/content/en/hosting/monitoring/production.md b/content/en/hosting/monitoring/production.md index 556e48ceb3..589875812e 100644 --- a/content/en/hosting/monitoring/production.md +++ b/content/en/hosting/monitoring/production.md @@ -17,7 +17,7 @@ When you run CHT Watchdog in production, and it is publicly accessible on the In * ensuring if the server were to fail, you can recover the data -This guide assumes you have already [set up TLS](//hosting/cht/docker/adding-tls-certificates) on your CHT instance and have gone through [the Setup steps](//hosting/monitoring/setup) to deploy an instance of CHT Watchdog on server with a static IP and DNS entry, `monitor.example.com` for example. +This guide assumes you have already [set up TLS](/hosting/cht/docker/adding-tls-certificates) on your CHT instance and have gone through [the Setup steps](/hosting/monitoring/setup) to deploy an instance of CHT Watchdog on server with a static IP and DNS entry, `monitor.example.com` for example. > [!WARNING] > Always run Watchdog on a different server than the CHT Core. This ensures Watchdog doesn't fail if the CHT Core server fails and alerts will always be sent. The instructions assume you're connecting over the public Internet and no special VPN or routing is required. diff --git a/content/en/hosting/monitoring/setup.md b/content/en/hosting/monitoring/setup.md index 78b374f156..a6a10e5f97 100644 --- a/content/en/hosting/monitoring/setup.md +++ b/content/en/hosting/monitoring/setup.md @@ -115,7 +115,7 @@ docker compose up -d #### CHT Sync Data (Local) -With the [release of 1.1.0](https://github.com/medic/cht-watchdog/releases/tag/1.1.0), Watchdog now supports easily ingesting [CHT Sync](//hosting/analytics) data read in from a Postgres database (supports Postgres `>= 9.x`). +With the [release of 1.1.0](https://github.com/medic/cht-watchdog/releases/tag/1.1.0), Watchdog now supports easily ingesting [CHT Sync](/hosting/analytics) data read in from a Postgres database (supports Postgres `>= 9.x`). 1. Copy the example config file, so you can add the correct contents in them: ```shell diff --git a/content/en/releases/4_12_0.md b/content/en/releases/4_12_0.md index cca6e0f311..567ca84271 100644 --- a/content/en/releases/4_12_0.md +++ b/content/en/releases/4_12_0.md @@ -24,7 +24,7 @@ None. This release includes changes to the user interface which will improve the learnability of the CHT by aligning with the look and feel of other android apps. Below is a summary of the changes, all of which were covered in the [July Round-up Call](https://youtube.com/watch?v=NSFRQt378Ls&t=460s): - [Update to the overall CHT app Navigation experience](https://forum.communityhealthtoolkit.org/t/the-ui-evolution-of-the-cht/3515#navigation-6) -- Added the ability to temporarily [opt out](//community/contributing/code/core/feature-flags) of the new Navigation experience +- Added the ability to temporarily [opt out](/community/contributing/code/core/feature-flags) of the new Navigation experience - [Removal of opt out capabilities for Old Filter and Search](https://forum.communityhealthtoolkit.org/t/feature-removal-opting-out-of-two-ui-changes/3738) - [Removal of opt out capabilities for Old Action Bar](https://forum.communityhealthtoolkit.org/t/feature-removal-opting-out-of-two-ui-changes/3738) diff --git a/content/en/releases/4_2_0.md b/content/en/releases/4_2_0.md index 3f35cb62d4..df0a9985bd 100644 --- a/content/en/releases/4_2_0.md +++ b/content/en/releases/4_2_0.md @@ -26,7 +26,7 @@ None. The additive actions (creating reports, places, people, etc...) have moved from the bottom action bar to a Floating Action Button that opens a menu with all actions. This change aligns the CHT more closely with Android UX and [material design patterns](https://m3.material.io/components/menus/overview), and applies to the Messages, Reports, and Contacts tab. -NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](//community/contributing/code/core/feature-flags) documentation for more information. +NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](/community/contributing/code/core/feature-flags) documentation for more information. {{< cards cols=2 >}} {{< figure src="../images/4_2_0-7998-mobile-fab.png" class="left col-4 col-lg-4" >}} @@ -41,7 +41,7 @@ NOTE: The bottom action bar can be temporarily re-enabled for specific users by The Export, Edit, and Delete actions have moved from the bottom action bar to a new More Option (⋮) menu located on the top right side of the screen. This change aligns the CHT more closely with Android UX and [material design patterns](https://m3.material.io/components/menus/overview), and applies to the Messages, Reports, and Contacts tab. -NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](//community/contributing/code/core/feature-flags) documentation for more information. +NOTE: The bottom action bar can be temporarily re-enabled for specific users by granting them the `can_view_old_action_bar` permission; however, it will be completely removed in a future release. See the [Feature Flags](/community/contributing/code/core/feature-flags) documentation for more information. {{< cards >}} {{< figure src="../images/4_2_0-7872-mobile.png" class="left col-3 col-lg-3" >}} diff --git a/content/en/technical-overview/architecture/cht-interoperability.md b/content/en/technical-overview/architecture/cht-interoperability.md index 35edcc619f..e57846f0f8 100644 --- a/content/en/technical-overview/architecture/cht-interoperability.md +++ b/content/en/technical-overview/architecture/cht-interoperability.md @@ -11,4 +11,4 @@ aliases: - /core/overview/interoperability/ --- -[CHT Interoperability](//building/interoperability/) refers to the ability of different health information systems and applications to communicate with each other and exchange data seamlessly. With interoperability, patient information can be seen, exchanged, and used across different platforms. The information/data exchanged has to be understood across the different software for these systems to become interoperable. This is different from _integration_ which requires custom development to connect two specific systems. +[CHT Interoperability](/building/interoperability/) refers to the ability of different health information systems and applications to communicate with each other and exchange data seamlessly. With interoperability, patient information can be seen, exchanged, and used across different platforms. The information/data exchanged has to be understood across the different software for these systems to become interoperable. This is different from _integration_ which requires custom development to connect two specific systems. diff --git a/content/en/technical-overview/architecture/cht-sync.md b/content/en/technical-overview/architecture/cht-sync.md index e1562a239b..cdf04762f7 100644 --- a/content/en/technical-overview/architecture/cht-sync.md +++ b/content/en/technical-overview/architecture/cht-sync.md @@ -16,7 +16,7 @@ aliases: CHT Sync is an integrated solution designed to enable data synchronization between CouchDB and PostgreSQL for the purpose of analytics. It combines several technologies to achieve this synchronization and provides an efficient workflow for data processing and visualization. The synchronization occurs in near real-time, ensuring that the data displayed on dashboards is up-to-date. -Read more about setting up [CHT Sync](//hosting/analytics). +Read more about setting up [CHT Sync](/hosting/analytics). diff --git a/content/en/technical-overview/architecture/cht-watchdog.md b/content/en/technical-overview/architecture/cht-watchdog.md index a6041a640b..043b70a1f9 100644 --- a/content/en/technical-overview/architecture/cht-watchdog.md +++ b/content/en/technical-overview/architecture/cht-watchdog.md @@ -12,7 +12,7 @@ aliases: - /technical-overview/cht-watchdog/ --- -CHT Watchdog is deployed on a separate server so that you can watch for, and alert on, any critical issues with the CHT Core. Read more about [setting up CHT Watchdog](//hosting/monitoring/setup). +CHT Watchdog is deployed on a separate server so that you can watch for, and alert on, any critical issues with the CHT Core. Read more about [setting up CHT Watchdog](/hosting/monitoring/setup). diff --git a/content/en/technical-overview/architecture/overview.md b/content/en/technical-overview/architecture/overview.md index 7fddf567e6..8c7f89accc 100644 --- a/content/en/technical-overview/architecture/overview.md +++ b/content/en/technical-overview/architecture/overview.md @@ -69,7 +69,7 @@ A command-line interface tool to manage and configure CHT application. The A suite of tools for extracting and normalizing data from the Core Framework's CouchDB, and rendering the data in analytics dashboards to visualize key data for a CHT deployment. -Read more detail on the CHT Sync [overview page](//technical-overview/architecture/cht-sync), the [GitHub repository](https://github.com/medic/cht-sync), or the [technical overview](/technical-overview/architecture/cht-sync). +Read more detail on the CHT Sync [overview page](/technical-overview/architecture/cht-sync), the [GitHub repository](https://github.com/medic/cht-sync), or the [technical overview](/technical-overview/architecture/cht-sync). ## CHT Watchdog @@ -77,7 +77,7 @@ Monitoring and alerting for the CHT Core Framework to ensure CHWs are able to de ## CHT Android -CHT Web Application works in the browser or wrapped in the [CHT Android](//technical-overview/architecture/cht-android) app which allows for project branding, sets the project URL, and hides browser elements like the URL bar. The app also provides some deeper integration with other android apps and native phone functions that are otherwise unavailable to webapps. +CHT Web Application works in the browser or wrapped in the [CHT Android](/technical-overview/architecture/cht-android) app which allows for project branding, sets the project URL, and hides browser elements like the URL bar. The app also provides some deeper integration with other android apps and native phone functions that are otherwise unavailable to webapps. ## CHT Gateway From 15f502f90222fd8470f2391d654927fdb7da0ee7 Mon Sep 17 00:00:00 2001 From: Andra Blaj Date: Fri, 3 Oct 2025 14:46:48 +0300 Subject: [PATCH 4/5] fix more links --- content/en/building/_index.md | 2 +- content/en/building/branding/android.md | 12 +- .../building/branding/application-graphics.md | 6 +- content/en/building/branding/publishing.md | 8 +- content/en/building/condition-cards.md | 4 +- .../building/contact-management/contacts.md | 6 +- .../contact-management/moving-contacts.md | 2 +- .../contact-summary-overview.md | 4 +- .../contact-summary-templated.md | 10 +- content/en/building/forms/_index.md | 8 +- content/en/building/forms/app.md | 12 +- .../building/forms/configuring/form-inputs.md | 38 +- .../building/forms/configuring/multimedia.md | 2 +- content/en/building/forms/contact.md | 10 +- content/en/building/forms/form-properties.md | 4 +- content/en/building/implementations.md | 2 +- content/en/building/integrations/android.md | 2 +- content/en/building/integrations/custom.md | 22 +- content/en/building/integrations/dhis2.md | 2 +- content/en/building/integrations/openmrs.md | 12 +- content/en/building/integrations/oppia.md | 14 +- content/en/building/integrations/rapidpro.md | 20 +- .../building/interoperability/cht-config.md | 2 +- content/en/building/interoperability/ltfu.md | 4 +- .../en/building/interoperability/openhim.md | 18 +- .../en/building/interoperability/openmrs.md | 14 +- .../en/building/interoperability/overview.md | 2 +- content/en/building/local-setup.md | 4 +- content/en/building/login.md | 2 +- .../gateways/gateway/configuration.md | 2 +- .../messaging/gateways/gateway/phones.md | 2 +- .../gateways/gateway/troubleshooting.md | 2 +- content/en/building/prerequisites.md | 2 +- .../en/building/reference/_partial_cht_api.md | 4 +- content/en/building/reference/api.md | 20 +- .../building/reference/app-settings/_index.md | 4 +- .../reference/app-settings/assetlinks.md | 8 +- .../reference/app-settings/oidc_provider.md | 6 +- .../reference/app-settings/token_login.md | 2 +- .../reference/app-settings/transitions.md | 20 +- .../app-settings/user-permissions.md | 6 +- .../en/building/reference/extension-libs.md | 4 +- .../en/building/reports/defining-reports.md | 4 +- .../en/building/reports/reports-overview.md | 8 +- content/en/building/targets/target-widgets.md | 18 +- content/en/building/targets/targets-js.md | 2 +- content/en/building/tasks/complex-tasks.md | 20 +- .../managing-tasks/launch-contact-form.md | 4 +- .../tasks/managing-tasks/pass-data-to-form.md | 10 +- .../tasks/managing-tasks/query-task-data.md | 12 +- .../managing-tasks/task-schema-parameters.md | 10 +- .../building/tasks/simple-priority-score.md | 4 +- content/en/building/tasks/simple-tasks.md | 22 +- content/en/building/tasks/tasks-js.md | 10 +- .../en/building/training/users-bulk-load.md | 4 +- .../en/building/translations/localizing.md | 6 +- content/en/building/translations/overview.md | 10 +- content/en/building/tutorials/app-forms.md | 10 +- .../building/tutorials/application-tests.md | 24 +- content/en/building/tutorials/sms-forms.md | 14 +- .../en/building/tutorials/sms-schedules.md | 8 +- content/en/building/users.md | 2 +- .../building/workflows/workflows-overview.md | 2 +- .../code/android/development-setup.md | 2 +- .../contributing/code/android/releasing.md | 2 +- .../code/core/apdex-automation-tests.md | 2 +- .../contributing/code/core/automated-tests.md | 4 +- .../contributing/code/core/feature-flags.md | 2 +- .../contributing/code/releasing/_index.md | 2 +- .../contributing/code/repository-checklist.md | 2 +- .../contributing/code/static-analysis.md | 10 +- .../contributing/code/style-guide.md | 2 +- .../code/troubleshooting/obtaining-logs.md | 2 +- .../community/contributing/code/workflow.md | 16 +- .../contributing/docs/style-guide.md | 9 +- .../community/contributing/docs/workflow.md | 4 +- .../en/community/contributing/translations.md | 6 +- content/en/design/best-practices.md | 4 +- content/en/design/interface/icons/_index.md | 2 +- content/en/design/mapping-hierarchy.md | 4 +- .../focus-group-discussions.md | 2 +- .../user-interviews.md | 4 +- content/en/hosting/SSO/_index.md | 4 +- content/en/hosting/SSO/technical.md | 2 +- .../hosting/analytics/building-dbt-models.md | 12 +- content/en/hosting/couch2pg/_index.md | 2 +- .../hosting/couch2pg/couch2pg-oom-errors.md | 2 +- content/en/hosting/couch2pg/couch2pg-setup.md | 4 +- content/en/hosting/couch2pg/migration.md | 4 +- .../hosting/couch2pg/setup-and-devlopment.md | 2 +- .../reference-apps/covid-rdt-reference-app.md | 16 +- content/en/reference-apps/direct-to-client.md | 2 +- content/en/reference-apps/learning-care.md | 2 +- content/en/reference-apps/maternal-newborn.md | 4 +- .../pharmacovigilance-reference-app.md | 4 +- content/en/reference-apps/pih.md | 4 +- content/en/releases/2_13_0.md | 4 +- content/en/releases/2_16_0.md | 522 +++++++++--------- content/en/releases/3_10_0.md | 2 +- content/en/releases/3_11_0.md | 2 +- content/en/releases/3_14_0.md | 6 +- content/en/releases/3_17_0.md | 4 +- content/en/releases/3_4_0.md | 2 +- content/en/releases/4_0_0.md | 6 +- content/en/releases/4_17_0.md | 6 +- content/en/releases/4_18_0.md | 16 +- content/en/releases/4_19_0.md | 2 +- content/en/releases/4_1_0.md | 4 +- content/en/releases/4_20_0.md | 4 +- content/en/releases/4_21_0.md | 6 +- content/en/releases/_index.md | 260 ++++----- .../architecture/cht-core.md | 2 +- .../architecture/overview.md | 4 +- content/en/technical-overview/data/_index.md | 2 +- .../analytics/data-flows-for-analytics.md | 4 +- .../data/analytics/muting_in_dashboards.md | 2 +- .../analytics/querying_apdex_telemetry.md | 2 +- .../querying_training_card_telemetry.md | 4 +- .../en/technical-overview/data/db-schema.md | 8 +- .../data/performance/telemetry.md | 2 +- content/en/why-the-cht/_index.md | 12 +- 121 files changed, 781 insertions(+), 786 deletions(-) diff --git a/content/en/building/_index.md b/content/en/building/_index.md index 591829e6f5..3740d6e5ec 100644 --- a/content/en/building/_index.md +++ b/content/en/building/_index.md @@ -11,7 +11,7 @@ description: > This section provides an introduction to CHT Applications, provides some sample CHT Applications, and provides guides and reference materials for those wanting to build a CHT Application or deploy an existing one. -Community Health Toolkit (CHT) Applications are digital health tools built using the [CHT Core Framework]({{< ref "core" >}}). The Core Framework provides a foundation on which custom CHT Applications are built. Since all CHT Applications share the same foundation, they also share capabilities and attributes. For example, all CHT Applications share a similar user-interface and share the same look-and-feel. All CHT Applications can be built to scale, can run across a variety of devices, support [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}) experiences, and support most languages. These baseline capabilities are foundational across all CHT Applications. Read more about this in [Why the CHT?]({{< ref "why-the-cht" >}}). +Community Health Toolkit (CHT) Applications are digital health tools built using the [CHT Core Framework](/core). The Core Framework provides a foundation on which custom CHT Applications are built. Since all CHT Applications share the same foundation, they also share capabilities and attributes. For example, all CHT Applications share a similar user-interface and share the same look-and-feel. All CHT Applications can be built to scale, can run across a variety of devices, support [Offline-First](/technical-overview/concepts/offline-first) experiences, and support most languages. These baseline capabilities are foundational across all CHT Applications. Read more about this in [Why the CHT?](/why-the-cht). To create a digital health tool using the Community Health Toolkit, you'll need to build a CHT Application or re-use an existing CHT Application. diff --git a/content/en/building/branding/android.md b/content/en/building/branding/android.md index 419278ed35..0537c59f1d 100644 --- a/content/en/building/branding/android.md +++ b/content/en/building/branding/android.md @@ -49,7 +49,7 @@ To proceed you need to have ready the following: - The app logo and title. - Translations for your supported languages (most flavors don't need to customize translations though). -Also be sure to have a working **[Development Environment]({{< ref "community/contributing/code/android/development-setup" >}})**. +Also be sure to have a working **[Development Environment](/community/contributing/code/android/development-setup)**. While you should use your own branding, the [CHT logo](./CHT.logo.512.png) is available to use if so desired. @@ -233,11 +233,11 @@ Releasing a new flavor requires the following steps: 1. Make a pull request to the release branch in the CHT Android repository. 2. Once approved it's recommended to create an alpha version to do final tests. 3. Merge the pull request. -4. [Release the flavor]({{< ref "community/contributing/code/android/releasing" >}}). +4. [Release the flavor](/community/contributing/code/android/releasing). ### 6. Publish the app -The last step is to publish it in the Play Store, or whatever option best suit your needs. Checkout the [Publishing]({{< ref "building/branding/publishing" >}}) page to see all the options available and instructions. +The last step is to publish it in the Play Store, or whatever option best suit your needs. Checkout the [Publishing](/building/branding/publishing) page to see all the options available and instructions. ## Android App Links verification *Supported for CHT Core 4.7.0+ and CHT Android 1.3.0+* @@ -248,14 +248,14 @@ Starting with Android 12, Android supports associating an app with a domain and Since CHT Core version 4.7.0, the CHT supports serving `assetlinks.json` by adding it to your app settings. All you have to do to make the CHT serve your assetlinks at `/.well-known/assetlinks.json` is to: -1. Ensure your flavor of cht-android [has a valid keystore]({{< ref "#3-generate-a-new-keystore" >}}). +1. Ensure your flavor of cht-android [has a valid keystore](/#3-generate-a-new-keystore). 2. Use the `keytool` utility (included with your Java SDK) to get your app's cert fingerprint: ```shell keytool -list -v -keystore ./path/to/release-key.keystore # or alternatively: keytool -printcert -jarfile ./path/to/project.apk ``` -3. Set the cert fingerprint in the [`assetlinks` configuration]({{< ref "building/reference/app-settings/assetlinks" >}}) for your CHT instance and deploy it to your server with cht-conf. +3. Set the cert fingerprint in the [`assetlinks` configuration](/building/reference/app-settings/assetlinks) for your CHT instance and deploy it to your server with cht-conf. #### Note for Apps Using Google Play Signing @@ -277,7 +277,7 @@ There are different ways to verify your setup works and we'll go through a few o #### Using Android Debug Bridge `adb` -1. To install the `adb` command, follow the instructions under the [Development Environment > Debug tool adb]({{< ref "community/contributing/code/android/development-setup#debug-tool-adb" >}}) section. +1. To install the `adb` command, follow the instructions under the [Development Environment > Debug tool adb](/community/contributing/code/android/development-setup#debug-tool-adb) section. 2. With the phone connected to your computer, open a command line session and write the following command: `adb shell pm get-app-links ` where `` is your application ID. The output of this command should look like this: diff --git a/content/en/building/branding/application-graphics.md b/content/en/building/branding/application-graphics.md index 1d1bfb6f14..fc74b74ee0 100644 --- a/content/en/building/branding/application-graphics.md +++ b/content/en/building/branding/application-graphics.md @@ -18,7 +18,7 @@ You will cover site branding, partner logos, header tab icons, and app icons (us ## Required Resources -You should have a functioning [CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}) and completed a [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) setup. +You should have a functioning [CHT instance with `cht-conf` installed locally](/building/local-setup) and completed a [project folder](/building/local-setup#3-create-and-upload-a-blank-project) setup. ## Implementation Steps @@ -223,6 +223,6 @@ To modify the icon used in contacts, you will need to edit the icon subkey in ap Finally run the command: `cht --local upload-app-settings` -To customise the icons used in tasks or the action bar, you will need to edit a form properties file and add an icon property as outline in [form properties]({{< ref "building/forms/form-properties" >}}) tutorial. +To customise the icons used in tasks or the action bar, you will need to edit a form properties file and add an icon property as outline in [form properties](/building/forms/form-properties) tutorial. -To customise the icons used in targets, you will need to add an icon property in a target's definition as shown in the [targets]({{< ref "building/targets/target-widgets" >}}) tutorial. +To customise the icons used in targets, you will need to add an icon property in a target's definition as shown in the [targets](/building/targets/target-widgets) tutorial. diff --git a/content/en/building/branding/publishing.md b/content/en/building/branding/publishing.md index e10275f83b..90a8c8ac4b 100644 --- a/content/en/building/branding/publishing.md +++ b/content/en/building/branding/publishing.md @@ -18,7 +18,7 @@ aliases: > ## Publishing -Once the flavor is [bui````lt]({{< ref "building/branding/android" >}}) there are many different ways to publish the binaries for installation. +Once the flavor is [bui````lt](/building/branding/android) there are many different ways to publish the binaries for installation. ### Google Play Store @@ -41,17 +41,17 @@ For a more detailed explanation, follow this [doc](https://support.google.com/go #### New App in the Play Store -Remember that when the app is created in the Play Store, it's required to choose the way the app will be signed by Google: we upload the signed AAB files, but then Google creates optimized versions of the app in .apk format. The app has to be configured to use the same signing and upload signatures by Google. Choose to upload a "Java keystore", the Play Console will require a file encrypted with a tool named PEPK, that file is `_private_key.pepk` generated when following the instructions of [New brand]({{< ref "building/branding/android" >}}) (the button to upload the `.pepk` in the Play Console may say "Upload generated ZIP" although the PEPK file doesn't look like a .zip file). +Remember that when the app is created in the Play Store, it's required to choose the way the app will be signed by Google: we upload the signed AAB files, but then Google creates optimized versions of the app in .apk format. The app has to be configured to use the same signing and upload signatures by Google. Choose to upload a "Java keystore", the Play Console will require a file encrypted with a tool named PEPK, that file is `_private_key.pepk` generated when following the instructions of [New brand](/building/branding/android) (the button to upload the `.pepk` in the Play Console may say "Upload generated ZIP" although the PEPK file doesn't look like a .zip file). > [!NOTE] -> New apps cannot longer be uploaded with the APK format in the Play Store. Apps created before Aug 1, 2021 can still be updated with `.apk` files, but new ones needs to be uploaded with the Android App Bundle format (`.aab`). Checkout the [Artifact formats]({{< ref "community/contributing/code/android/development-setup#artifact-formats" >}}) section. +> New apps cannot longer be uploaded with the APK format in the Play Store. Apps created before Aug 1, 2021 can still be updated with `.apk` files, but new ones needs to be uploaded with the Android App Bundle format (`.aab`). Checkout the [Artifact formats](/community/contributing/code/android/development-setup#artifact-formats) section. ### Side loading This method gives an app developer full control over installation. It is also possible to do the installation without an internet connection which makes it ideal for remote installation, or to save bandwidth when performing multiple installs. 1. In the phone settings [select the option](https://developer.android.com/distribute/marketing-tools/alternative-distribution#unknown-sources) to "opt in for installing unknown apps". -2. Download the correct APK on to the phone. It's important to select the right APK for the instruction set and Android version, as documented [in this table]({{< ref "community/contributing/code/android/development-setup#apks" >}}). This is likely easiest done by using the phone's browser to navigate to the download page. +2. Download the correct APK on to the phone. It's important to select the right APK for the instruction set and Android version, as documented [in this table](/community/contributing/code/android/development-setup#apks). This is likely easiest done by using the phone's browser to navigate to the download page. 3. After downloading, you should be prompted to install the APK. ### F-Droid diff --git a/content/en/building/condition-cards.md b/content/en/building/condition-cards.md index 988514b7eb..e5706423df 100644 --- a/content/en/building/condition-cards.md +++ b/content/en/building/condition-cards.md @@ -32,7 +32,7 @@ Condition cards have several configurable elements including: ## Required Resources -You should have a functioning [CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}), completed a [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) setup, and an [assessment form]({{< ref "building/tutorials/app-forms" >}}). +You should have a functioning [CHT instance with `cht-conf` installed locally](/building/local-setup), completed a [project folder](/building/local-setup#3-create-and-upload-a-blank-project) setup, and an [assessment form](/building/tutorials/app-forms). ## Implementation Steps @@ -40,7 +40,7 @@ Create a `contact-summary.templated.js` file if it doesn't exist. (This may have ### 1. Add Dependencies and Variable Definitions -Add the following dependencies and variable definitions at the top of the file (some of them may have been added from the [contact summary tutorial]({{< ref "building/contact-summary/contact-summary-overview" >}})): +Add the following dependencies and variable definitions at the top of the file (some of them may have been added from the [contact summary tutorial](/building/contact-summary/contact-summary-overview)): ```javascript const thisContact = contact; diff --git a/content/en/building/contact-management/contacts.md b/content/en/building/contact-management/contacts.md index e07f0c0a67..95d9203d09 100644 --- a/content/en/building/contact-management/contacts.md +++ b/content/en/building/contact-management/contacts.md @@ -19,9 +19,9 @@ aliases: “People” is the generic name used for individuals in apps built with the Core Framework. They can be patients, family members, nurses or health workers. Anyone with a profile in your app is a person. -“Places” is the generic name that represents a level in the [hierarchy]({{< ref "building/workflows/hierarchy" >}}). “People” belong to “places”, and “places” belong to other higher level “places” in the hierarchy. A “place” could be a geographic area, like a district with the "people" associated to it being health officers. A "place" could also be a structure in the health system, such as a health facility, and the "people" associated to it being nurses. In deployments with CHWs, the lowest "place" in the hierarchy often represents individual households or families, and the individual members of that household are the "people" associated to it. +“Places” is the generic name that represents a level in the [hierarchy](/building/workflows/hierarchy). “People” belong to “places”, and “places” belong to other higher level “places” in the hierarchy. A “place” could be a geographic area, like a district with the "people" associated to it being health officers. A "place" could also be a structure in the health system, such as a health facility, and the "people" associated to it being nurses. In deployments with CHWs, the lowest "place" in the hierarchy often represents individual households or families, and the individual members of that household are the "people" associated to it. -Users can access their “people” and “places” from the **People** tab. The permissions set for your role and your placement in the hierarchy will determine which contacts you’re able to see. Advanced configuration options are available for a specific offline user role to manage what [level of contact data]({{< ref "technical-overview/data/performance/replication#contact-depth" >}}) is downloaded and stored on their device. +Users can access their “people” and “places” from the **People** tab. The permissions set for your role and your placement in the hierarchy will determine which contacts you’re able to see. Advanced configuration options are available for a specific offline user role to manage what [level of contact data](/technical-overview/data/performance/replication#contact-depth) is downloaded and stored on their device. {{< figure src="people-desktop.png" link="people-desktop.png" class="right col-6 col-lg-8 bordered-figure" >}} @@ -136,7 +136,7 @@ _(Added in CHT `4.19.0`)_ {{< figure link="duplicate-contact-screenshot.png" src="duplicate-contact-screenshot.png" class="right col-6 col-lg-8 bordered-figure">}} {{< /cards >}} -One major challenge when collecting contact data is ensuring users do not inadvertently enter duplicate records for the same contact. It is important to train users on the [searching]({{< ref "#searching" >}}) functionality described above as this will allow them to find the desired profile of a previously recorded contact instead of creating a duplicate record for the same person or place. +One major challenge when collecting contact data is ensuring users do not inadvertently enter duplicate records for the same contact. It is important to train users on the [searching](/#searching) functionality described above as this will allow them to find the desired profile of a previously recorded contact instead of creating a duplicate record for the same person or place. The CHT also supports automatically detecting when a contact being created or edited by a user matches an existing contact record. If a duplicate contact is detected, the user will be given the option of proceeding to the profile of the existing contact. Alternatively, the user can choose to override the duplicate detection logic and continue creating/editing the contact as originally intended. diff --git a/content/en/building/contact-management/moving-contacts.md b/content/en/building/contact-management/moving-contacts.md index bca9f36593..dac5f4330e 100644 --- a/content/en/building/contact-management/moving-contacts.md +++ b/content/en/building/contact-management/moving-contacts.md @@ -28,7 +28,7 @@ docDirectoryPath | This action outputs files to local disk at this destination | Some constraints when moving contacts: -* **Allowed Parents** - When moving contacts on WebApp >v3.7, your chosen parent must be listed as a valid parent for the contact as defined in the [configuration for place hierarchy]({{< ref "building/reference/app-settings/hierarchy" >}}). For WebApp <v3.7, the default hierarchy is enforced. +* **Allowed Parents** - When moving contacts on WebApp >v3.7, your chosen parent must be listed as a valid parent for the contact as defined in the [configuration for place hierarchy](/building/reference/app-settings/hierarchy). For WebApp <v3.7, the default hierarchy is enforced. * **Circular Hierarchy** - Nobody's parent can ever be themself or their child. * **Primary Contacts** - Primary contacts must be a descendant of the place for which they are the primary contact. You may need to select a new primary contact for a place through the WebApp if you'd like to move a primary contact to a new place in the hierarchy. * **Minification** - Due to contact "minification" (#2635) which was implemented in v2.13, this script should not be used for versions prior to v2.13. diff --git a/content/en/building/contact-summary/contact-summary-overview.md b/content/en/building/contact-summary/contact-summary-overview.md index d0f4663e15..f9c961946a 100644 --- a/content/en/building/contact-summary/contact-summary-overview.md +++ b/content/en/building/contact-summary/contact-summary-overview.md @@ -20,13 +20,13 @@ You will be adding a contact summary that displays information about a person's ## Brief Overview of Key Concepts -Each *field* that can be shown on a contact’s profile is defined as an object in the *[fields array]({{< ref "building/contact-summary/contact-summary-templated#contact-summarytemplatedjs-fields" >}})* of `contact-summary.templated.js`. +Each *field* that can be shown on a contact’s profile is defined as an object in the *[fields array](/building/contact-summary/contact-summary-templated#contact-summarytemplatedjs-fields)* of `contact-summary.templated.js`. The *properties* for each object determine how and when the field is shown. ## Required Resources -You should have a functioning [CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}), and completed a [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) setup. +You should have a functioning [CHT instance with `cht-conf` installed locally](/building/local-setup), and completed a [project folder](/building/local-setup#3-create-and-upload-a-blank-project) setup. ## Implementation Steps diff --git a/content/en/building/contact-summary/contact-summary-templated.md b/content/en/building/contact-summary/contact-summary-templated.md index cffe68ab80..31fe822826 100644 --- a/content/en/building/contact-summary/contact-summary-templated.md +++ b/content/en/building/contact-summary/contact-summary-templated.md @@ -21,15 +21,15 @@ Helper variables and functions for the contact summary can be defined in `contac | `contact` | The currently selected contact. This has minimal stubs for the `contact.parent`, so if you want to refer to a property on the parent use `lineage` below.| | `reports` | An array of reports for the contact or for any of the contact's `person` children. Note that if the contact has more than 500 reports, only the 500 with the latest `reported_date` values will be provided. Prior to version `4.7.0`, only 50 reports were provided. | | `lineage` | An array of the contact's parents (2.13+), eg `lineage[0]` is the parent, `lineage[1]` is the grandparent, etc. Each lineage entry has full information for the contact, so you can use `lineage[1].contact.phone`. `lineage` will include only those contacts which are visible to the logged in profile | -| `targetDoc` | Doc with [`target`]({{< ref "technical-overview/data/db-schema#targets" >}} ) document of the contact, hydrated with the config information of every target it contains a value for. If there is no target document available (for example when viewing a contact that does not upload targets), this value will be `undefined`. This value might also be `undefined` if the contact has not yet synced the current target document. Added in `3.9.0`. | +| `targetDoc` | Doc with [`target`](/technical-overview/data/db-schema#targets) document of the contact, hydrated with the config information of every target it contains a value for. If there is no target document available (for example when viewing a contact that does not upload targets), this value will be `undefined`. This value might also be `undefined` if the contact has not yet synced the current target document. Added in `3.9.0`. | | `uhcStats` | Object containing UHC stats information. Added in `v3.12.0` | -| `uhcStats.uhcInterval` | Object containing the start and end date of UHC reporting period, it is calculated from the `uhc.visit_count.month_start_date` defined in the [app settings]({{< ref "/building/reference/app-settings/#app_settingsjson" >}}). | +| `uhcStats.uhcInterval` | Object containing the start and end date of UHC reporting period, it is calculated from the `uhc.visit_count.month_start_date` defined in the [app settings](//building/reference/app-settings/#app_settingsjson). | | `uhcStats.uhcInterval.start` | Timestamp, start date of the UHC reporting period. | | `uhcStats.uhcInterval.end` | Timestamp, end date of the UHC reporting period. | -| `uhcStats.homeVisits` | Object containing the contact's home visits stats. The [contact's type]({{< ref "/building/reference/app-settings/hierarchy.md#app_settingsjson-contact_types" >}}) should have `count_visits` enabled and the [UHC visit count settings]({{< ref "/building/reference/app-settings/#app_settingsjson" >}}) should be defined, additionally this information is only available for users that have `can_view_uhc_stats` permission and that are not System Administrators. | +| `uhcStats.homeVisits` | Object containing the contact's home visits stats. The [contact's type](//building/reference/app-settings/hierarchy.md#app_settingsjson-contact_types) should have `count_visits` enabled and the [UHC visit count settings](//building/reference/app-settings/#app_settingsjson) should be defined, additionally this information is only available for users that have `can_view_uhc_stats` permission and that are not System Administrators. | | `uhcStats.homeVisits.lastVisitedDate` | Timestamp, date of contact's last home visit. | | `uhcStats.homeVisits.count` | Number of contact's home visits in the current reporting interval. | -| `uhcStats.homeVisits.countGoal` | Number, home visits goal, defined in the [UHC visit count settings]({{< ref "/building/reference/app-settings/#app_settingsjson" >}}). | +| `uhcStats.homeVisits.countGoal` | Number, home visits goal, defined in the [UHC visit count settings](//building/reference/app-settings/#app_settingsjson). | | `cht` | Object containing the [CHT API](#cht-api) for contact summary, targets and tasks. Added in `v3.12.0` | ## CHT API @@ -83,7 +83,7 @@ Each condition card is defined as a card object in the `cards` array of `contact ## Care Guides -Each care guide accessible from a contact profile is defined as an [App Form]({{< ref "building/forms/app" >}}). Context information can be provided to forms via the `context` object of `contact-summary.templated.js`. +Each care guide accessible from a contact profile is defined as an [App Form](/building/forms/app). Context information can be provided to forms via the `context` object of `contact-summary.templated.js`. To show an App Form on a contact's profile, the form's `expression` field in its properties file must evaluate to true for that contact. The context information from the profile is accessible as the variable `summary`. diff --git a/content/en/building/forms/_index.md b/content/en/building/forms/_index.md index a3a78117d8..b83fe0ab5f 100644 --- a/content/en/building/forms/_index.md +++ b/content/en/building/forms/_index.md @@ -12,12 +12,12 @@ aliases: Forms are a building block of all CHT apps. They are used when creating or editing contacts, and when completing a care guide or survey within the app. Forms are also used to interpret SMS interactions with the CHT. -When a completed form is submitted, it is treated as a Report in the app. All reports can be viewed in the [Reports tab]({{< ref "building/reports" >}}) by those with the proper access within the [hierarchy]({{< ref "building/workflows/hierarchy" >}}). +When a completed form is submitted, it is treated as a Report in the app. All reports can be viewed in the [Reports tab](/building/reports) by those with the proper access within the [hierarchy](/building/workflows/hierarchy). There are four different types of forms: -- [**Contact Forms**]({{< ref "building/forms/contact" >}}): used to create and edit contacts. Defined as CHT-enhanced XForms. -- [**App Forms**]({{< ref "building/forms/app" >}}): serve as actions within the app, such as a task or an action. Defined as CHT-enhanced XForms. -- [**Collect Forms**]({{< ref "building/forms/collect" >}}): used to render forms in Medic Collect. Defined as ODK XForms and need a corresponding JSON form to receive data in CHT. +- [**Contact Forms**](/building/forms/contact): used to create and edit contacts. Defined as CHT-enhanced XForms. +- [**App Forms**](/building/forms/app): serve as actions within the app, such as a task or an action. Defined as CHT-enhanced XForms. +- [**Collect Forms**](/building/forms/collect): used to render forms in Medic Collect. Defined as ODK XForms and need a corresponding JSON form to receive data in CHT. Forms that can be completed in the app are built using a CHT-enhanced version of [ODK XForms](https://opendatakit.github.io/xforms-spec/) notation -- a XML definition of the structure and format for a set of questions. Since writing raw XML can be tedious, the [XLSForm standard](http://xlsform.org/) is commonly used to define forms. The [cht-conf](https://github.com/medic/cht-conf) command line tool can be used to convert to the XForm format and include the form in a CHT application. The instructions on this site assume some knowledge of XLSForm. diff --git a/content/en/building/forms/app.md b/content/en/building/forms/app.md index 0dc9cfa726..32fdd40e35 100644 --- a/content/en/building/forms/app.md +++ b/content/en/building/forms/app.md @@ -11,14 +11,14 @@ aliases: - /apps/reference/forms/app --- -App forms are used for care guides within the web app, whether accessed in browser or via the Android app. When a user completes an app form, the contents are saved in the database with the type `data_record`. These docs are known in the app as [Reports]( {{< ref "building/reports" >}} ). +App forms are used for care guides within the web app, whether accessed in browser or via the Android app. When a user completes an app form, the contents are saved in the database with the type `data_record`. These docs are known in the app as [Reports]( {{< ref "building/reports" >}}). App forms are defined by the following files: - A XML form definition using a CHT-enhanced ODK XForm format - A XLSForm form definition, easier to write and converts to the XForm (optional) - Meta information in the `{form_name}.properties.json` file (optional) -- Media files in the `{form_name}-media` directory (optional). How to [include multimedia files]( {{< ref "building/forms/configuring/multimedia" >}} ). +- Media files in the `{form_name}-media` directory (optional). How to [include multimedia files]( {{< ref "building/forms/configuring/multimedia" >}}). ## XForm @@ -106,7 +106,7 @@ If you want to make the timer mandatory so users must wait for the timer to comp {{< /callout >}} ### Contact Selector -A dropdown field to search and select a person or place, and save their UUID in the report. The contact's data will also be mapped to fields with matching names within the containing group. If the contact selector's appearance includes `bind-id-only`, the associated data fields are not mapped. See [the form input guide]({{< ref "building/forms/configuring/form-inputs#contact-selector" >}}) for an example. +A dropdown field to search and select a person or place, and save their UUID in the report. The contact's data will also be mapped to fields with matching names within the containing group. If the contact selector's appearance includes `bind-id-only`, the associated data fields are not mapped. See [the form input guide](/building/forms/configuring/form-inputs#contact-selector) for an example. ### Rapid Diagnostic Test Capture Take a picture of a Rapid Diagnotistic Test and save it with the report. Works with [rdt-capture Android application](https://github.com/medic/rdt-capture/). To use create a string field with appearance `mrdt-verify`. @@ -281,7 +281,7 @@ Calculates the number of whole calendar years between two dates. _Added in 4.2.0._ -This function invokes a configured [extension library]({{< ref "extension-libs" >}}). The first parameter is a string with the name of the library to execute, and any remaining parameters are passed through as is. For example, to calculate an average of two numbers, the xpath could be: `cht:extension-lib('average.js', /data/first, /data/second )`. +This function invokes a configured [extension library](/extension-libs). The first parameter is a string with the name of the library to execute, and any remaining parameters are passed through as is. For example, to calculate an average of two numbers, the xpath could be: `cht:extension-lib('average.js', /data/first, /data/second )`. ### `cht:strip-whitespace` @@ -312,7 +312,7 @@ _Added in 3.14.0._ This function converts a `date` to a `string` containing the value of the date formatted according to the [Bikram Sambat](https://en.wikipedia.org/wiki/Vikram_Samvat) calendar. -See also: [Bikram Sambat Datepicker]({{< ref "building/forms/app#cht-xform-widgets" >}}) +See also: [Bikram Sambat Datepicker](/building/forms/app#cht-xform-widgets) ### `z-score` @@ -349,7 +349,7 @@ The data used by this function needs to be added to CouchDB. The example below s ## Input data -`app` forms have access to a variety of [input data]({{< ref "building/forms/configuring/form-inputs#app-forms" >}}) depending on the source of the form. +`app` forms have access to a variety of [input data](/building/forms/configuring/form-inputs#app-forms) depending on the source of the form. ## CHT Special Fields diff --git a/content/en/building/forms/configuring/form-inputs.md b/content/en/building/forms/configuring/form-inputs.md index 095ad7791f..b3bc84cc93 100644 --- a/content/en/building/forms/configuring/form-inputs.md +++ b/content/en/building/forms/configuring/form-inputs.md @@ -19,9 +19,9 @@ CHT forms have access to varying amounts of input data depending on the type of Available data: -- [initial contact data]({{< ref "#initial-contact-data-in-contact-forms" >}}) -- [`inputs` data for user]({{< ref "#user-data" >}}) -- [Contact data via contact selector]({{< ref "#contact-selector" >}}) +- [initial contact data](/#initial-contact-data-in-contact-forms) +- [`inputs` data for user](/#user-data) +- [Contact data via contact selector](/#contact-selector) ### Initial contact data in `contact` forms @@ -38,7 +38,7 @@ Forms for adding contacts have access to a small group of fields contained in a #### Edit forms -Forms for editing contacts have access to _all the contact's current data_. These fields are contained in a top-level group that is named for the contact_type id of the contact being added (so `person`, `clinic`, etc). If fields in the top-level group are [edited by the form]({{< ref "building/forms/contact" >}}), these changes will be saved to the contact's doc. +Forms for editing contacts have access to _all the contact's current data_. These fields are contained in a top-level group that is named for the contact_type id of the contact being added (so `person`, `clinic`, etc). If fields in the top-level group are [edited by the form](/building/forms/contact), these changes will be saved to the contact's doc. In addition, the contact's `parent` data is hydrated so that the form has access to the data stored on the parent contact doc in the `parent` group. @@ -56,13 +56,13 @@ In addition, the contact's `parent` data is hydrated so that the form has access Available data: -- [`inputs` data for source]({{< ref "#form-source" >}}) -- [`inputs` data for contact]({{< ref "#inputs-data-for-contact-in-app-forms" >}}) -- [`contact-summary` data]({{< ref "#contact-summary-data" >}}) -- [`user-contact-summary` data]({{< ref "#user-contact-summary-data" >}}) -- [`inputs` data from task]({{< ref "#inputs-data-from-task" >}}) -- [`inputs` data for user]({{< ref "#user-data" >}}) -- [Contact data via contact selector]({{< ref "#contact-selector" >}}) +- [`inputs` data for source](/#form-source) +- [`inputs` data for contact](/#inputs-data-for-contact-in-app-forms) +- [`contact-summary` data](/#contact-summary-data) +- [`user-contact-summary` data](/#user-contact-summary-data) +- [`inputs` data from task](/#inputs-data-from-task) +- [`inputs` data for user](/#user-data) +- [Contact data via contact selector](/#contact-selector) ### Form source @@ -88,7 +88,7 @@ The `contact` group contains all the fields from the doc of the contact in conte ### `contact-summary` data -`app` forms with a contact in context can access the contact-summary data associated with the contact. This is done by referencing an instance named `contact-summary`. E.g. `instance('contact-summary')/context/${variable}`. See [the reference documentation]({{< ref "building/contact-summary/contact-summary-templated#care-guides" >}}) for more information. +`app` forms with a contact in context can access the contact-summary data associated with the contact. This is done by referencing an instance named `contact-summary`. E.g. `instance('contact-summary')/context/${variable}`. See [the reference documentation](/building/contact-summary/contact-summary-templated#care-guides) for more information. {{< callout type="info" >}} Contact summary data is not available in `contact` forms or in forms created from the "Reports" tab. @@ -102,14 +102,14 @@ Available since 4.21.0 When the logged in user has an associated contact, `app` forms can access the contact-summary data associated with the user's contact. -This is done by referencing an instance named `user-contact-summary`. E.g. `instance('user-contact-summary')/context/${variable}`. See [the reference documentation]({{< ref "building/contact-summary/contact-summary-templated#care-guides" >}}) for more information. +This is done by referencing an instance named `user-contact-summary`. E.g. `instance('user-contact-summary')/context/${variable}`. See [the reference documentation](/building/contact-summary/contact-summary-templated#care-guides) for more information. ### `inputs` data from task -`app` forms created via a task have access to any data [supplied by the task]({{< ref "building/tasks/managing-tasks/pass-data-to-form" >}}) in the `inputs` group. +`app` forms created via a task have access to any data [supplied by the task](/building/tasks/managing-tasks/pass-data-to-form) in the `inputs` group. -Additionally, these forms have access to the [contact data]({{< ref "#inputs-data-for-contact-in-app-forms" >}}) for the contact associated with the task. +Additionally, these forms have access to the [contact data](/#inputs-data-for-contact-in-app-forms) for the contact associated with the task. The following fields will also be available in the `inputs` group: @@ -120,7 +120,7 @@ The following fields will also be available in the `inputs` group: ## `user` data -Both `app` and `contact` forms can access the current user's data at `inputs/user`. The data provided is simply the [`user-settings` doc for the user]({{< ref "technical-overview/data/db-schema#users" >}}) (e.g. `org.couchdb.user:username`) plus an additional `language` field that contains the user's currently selected language code. +Both `app` and `contact` forms can access the current user's data at `inputs/user`. The data provided is simply the [`user-settings` doc for the user](/technical-overview/data/db-schema#users) (e.g. `org.couchdb.user:username`) plus an additional `language` field that contains the user's currently selected language code. {{< callout type="info" >}} The `user-settings` doc for the user is _NOT_ the same as the CHT _contact_ doc for the user. @@ -143,7 +143,7 @@ Both `app` and `contact` forms can access the current user's data at `inputs/use ### Loading the user's contact data -While the `inputs/user` group does not contain the user's contact data, it does contain the user's `contact_id` which can be used to load the contact doc via a [contact selector]({{< ref "#loading-contact-data-for-use-in-other-expressions" >}}). +While the `inputs/user` group does not contain the user's contact data, it does contain the user's `contact_id` which can be used to load the contact doc via a [contact selector](/#loading-contact-data-for-use-in-other-expressions). ## Contact selector @@ -218,9 +218,9 @@ In the following example, we are loading the name of the current user from the a ### Conditionally selecting/loading contact data for the current contact -[As noted above]({{< ref "#app-forms" >}}), when opening an `app` form with a contact in context (e.g. when opening the form from the "People" tab), the contact's data will be available in the `inputs/contact` group. However, this data _is not available_ when opening the form from the "Reports" tab since there is no contact in context. +[As noted above](/#app-forms), when opening an `app` form with a contact in context (e.g. when opening the form from the "People" tab), the contact's data will be available in the `inputs/contact` group. However, this data _is not available_ when opening the form from the "Reports" tab since there is no contact in context. -A common pattern for enabling consistent form behavior in this case is to use a contact selector in the `inputs/contact` group and make the `inputs` group only relevant when the default `source` value is not overridden (the `source` field is populated with specific values when the form is opened [from the "People" tab or from a task]({{< ref "#form-source" >}})). With this pattern, the contact selector will only be visible when the form is opened from the "Reports" tab and the user can select the contact they want to report on. This will ensure that the `inputs/contact` data is always available regardless of how the form is opened. +A common pattern for enabling consistent form behavior in this case is to use a contact selector in the `inputs/contact` group and make the `inputs` group only relevant when the default `source` value is not overridden (the `source` field is populated with specific values when the form is opened [from the "People" tab or from a task](/#form-source)). With this pattern, the contact selector will only be visible when the form is opened from the "Reports" tab and the user can select the contact they want to report on. This will ensure that the `inputs/contact` data is always available regardless of how the form is opened. Then, this contact data can be used to link the report created from the form to the person or place in context (or the person selected when opening the form). Getting the values for `_id` or `patient_id` and setting them to `patient_id` or `patient_uuid` on the final report will link that report to the contact. Then the report will be displayed on the contact's summary page. diff --git a/content/en/building/forms/configuring/multimedia.md b/content/en/building/forms/configuring/multimedia.md index 6978bc926b..5d0a7b5a6c 100644 --- a/content/en/building/forms/configuring/multimedia.md +++ b/content/en/building/forms/configuring/multimedia.md @@ -15,7 +15,7 @@ aliases: ## Multimedia Formats -There are many supported formats for video, audio, and images. We recommend using h.264(mpeg) for video, jpeg for images, and mp3 for audio. When creating videos or images keep in mind the dimensions and storage capabilities on phones that may be used. Lower end phones have smaller storage and screen sizes. When rendering images, video, and audio the CHT uses the browser's built in rendering tools. This means you can render any media format that is supported by the [minimum version of Chrome]({{< ref "releases/#dependencies" >}}). +There are many supported formats for video, audio, and images. We recommend using h.264(mpeg) for video, jpeg for images, and mp3 for audio. When creating videos or images keep in mind the dimensions and storage capabilities on phones that may be used. Lower end phones have smaller storage and screen sizes. When rendering images, video, and audio the CHT uses the browser's built in rendering tools. This means you can render any media format that is supported by the [minimum version of Chrome](/releases/#dependencies). List of Supported formats: - [video/audio](https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats) diff --git a/content/en/building/forms/contact.md b/content/en/building/forms/contact.md index 0648df2004..89c8188285 100644 --- a/content/en/building/forms/contact.md +++ b/content/en/building/forms/contact.md @@ -22,7 +22,7 @@ These forms are stored in the `forms/contact` sub-folder of the project config d ### Survey sheet -To collect information about the contact, use a top-level group with the [id of the contact_type]({{< ref "building/reference/app-settings/hierarchy" >}}) as the `name` of the group (e.g. `person` when adding or editing a person contact). Information in this group will be saved to the contact's document in the database. +To collect information about the contact, use a top-level group with the [id of the contact_type](/building/reference/app-settings/hierarchy) as the `name` of the group (e.g. `person` when adding or editing a person contact). Information in this group will be saved to the contact's document in the database. | type | name | label::en | |-------------|--------|--------------| @@ -40,7 +40,7 @@ The `parent`, `type`, and `name` fields are mandatory on forms that are adding c #### Input data -`contact` forms have access to a variety of [input data]({{< ref "building/forms/configuring/form-inputs#app-forms" >}}). +`contact` forms have access to a variety of [input data](/building/forms/configuring/form-inputs#app-forms). ### Settings sheet @@ -57,7 +57,7 @@ The meta information in the `{contact_type_id}-{create|edit}.properties.json` fi | `context` | _Added in `3.10`._ The contact form context defines when the form should be available in the app. Note: this applies only to the contact form, not the contacts themselves. | no | | `context.expression` | A JavaScript expression evaluated when a contact profile is viewed. This can limit which users have access to the contact form. [See below](#context-expression) for more details. | no | | `context.permission` | String permission key required to allow the user to view and submit this form. If blank, this defaults to allowing all access. | no | -| `duplicate_check` | _Added in `4.19`._ Allows for configuring or disabling the [duplicate detection logic]({{< ref "building/contact-management/contacts#duplicate-contact-detection" >}}) for a particular contact type. | no | +| `duplicate_check` | _Added in `4.19`._ Allows for configuring or disabling the [duplicate detection logic](/building/contact-management/contacts#duplicate-contact-detection) for a particular contact type. | no | | `duplicate_check.expression` | A JavaScript expression evaluated when submitting the contact form. The expression defines the logic used for determining when a contact is considered to be a duplicate. [See below](#duplicate-check-expression) for more details. | no | | `duplicate_check.disabled` | Boolean determining if the duplicate check should be run when submitting this contact form. Default is `false`. | no | @@ -65,7 +65,7 @@ The meta information in the `{contact_type_id}-{create|edit}.properties.json` fi The contact form context expression can be used to limit which users have access to the contact form. If the expression evaluates to `true`, the form will be listed as an available action on the proper contact profiles. -In the expression, the `user` input is available. (Note that unlike in the [app form expressions]({{< ref "building/forms/app#formsappform_namepropertiesjson" >}}), the `contact` and `summary` inputs are [not currently available](https://github.com/medic/cht-core/issues/6612) for contact form expressions.) +In the expression, the `user` input is available. (Note that unlike in the [app form expressions](/building/forms/app#formsappform_namepropertiesjson), the `contact` and `summary` inputs are [not currently available](https://github.com/medic/cht-core/issues/6612) for contact form expressions.) #### Duplicate Check Expression @@ -85,7 +85,7 @@ Always consider the nature and quality of your data. As data quality improves (e ##### Customizing the duplicate contact error message -The default message shown to the user when a duplicate contact is found [can be modified]({{< ref "building/translations/overview" >}}) by adding a custom translation for the `duplicate_check.contact.duplication_message` key. +The default message shown to the user when a duplicate contact is found [can be modified](/building/translations/overview) by adding a custom translation for the `duplicate_check.contact.duplication_message` key. Additionally, different messages can be shown for different contact types by setting `duplicate_check.contact.${contact_type_id}.duplication_message` keys. This can be useful if you want to prompt the user with the likely reason the duplicate contacts matched based on your custom duplicate check expression logic. diff --git a/content/en/building/forms/form-properties.md b/content/en/building/forms/form-properties.md index 296ba86d80..54205112b7 100644 --- a/content/en/building/forms/form-properties.md +++ b/content/en/building/forms/form-properties.md @@ -20,11 +20,11 @@ You will be adding meta-data and context to an assessment workflow that allows C ## Brief Overview of Key Concepts -*[Form context]({{< ref "building/forms/app#formsappform_namepropertiesjson" >}})* defines when and where the form should be available in the app. +*[Form context](/building/forms/app#formsappform_namepropertiesjson)* defines when and where the form should be available in the app. ## Required Resources -You should have a functioning [CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}), completed a [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) setup, and an [assessment form]({{< ref "building/tutorials/app-forms" >}}). +You should have a functioning [CHT instance with `cht-conf` installed locally](/building/local-setup), completed a [project folder](/building/local-setup#3-create-and-upload-a-blank-project) setup, and an [assessment form](/building/tutorials/app-forms). ## Implementation Steps diff --git a/content/en/building/implementations.md b/content/en/building/implementations.md index bd826783e9..ecf63cbb21 100644 --- a/content/en/building/implementations.md +++ b/content/en/building/implementations.md @@ -29,7 +29,7 @@ CHT implementations follow a process from beginning to end in order to deliver a Various people interact with CHT implementations at various stages. The list below may not be exhaustive but highlights bare minimum requirements for a successful implementation. In some cases, personas may have overlapping roles. - Project managers - They may also be referred to as program heads or program leads. They are involved in planning, coordinating and overseeing digital health projects. Although they oversee the entire implementation, they interact with the CHT implementation more closely during the implementation and evaluation stages. - Designers - They include service designers, user experience/user interface designers, product designers, graphic designers among others. Designers interact with CHT implementations during the design phase. They carry out field immersion visits to gather technical requirements from the prospective end users, program leads at MoH, policy makers among others. The technical requirements gathered inform the final application. Product and UI/UX designers are involved in the design and evaluation phases to explore opportunities for improvement and user experience optimization. -- Developers - they include app developers, core developers and software developers who are involved in the building stage. App developers build custom applications based on the CHT core. These apps are composed of application and contact forms, application settings among other configurations. Core developers contribute to the [CHT Core framework]({{< ref "core" >}}) that powers the mobile apps. +- Developers - they include app developers, core developers and software developers who are involved in the building stage. App developers build custom applications based on the CHT core. These apps are composed of application and contact forms, application settings among other configurations. Core developers contribute to the [CHT Core framework](/core) that powers the mobile apps. - System administrators - they include database administrators, security engineers, site reliability engineers, devOps engineers and network managers. They are responsible for configuration of computers, servers, databases, pipelines and infrastructure of CHT applications, monitoring health status of the infrastructure and application such as performance, server resources utilization, and uptime. They interact with CHT implementations at the planning, hosting and support stages. - Technical support team - they include information communication and technology (ICT) officers and monitoring & evaluation officers. ICT officers are responsible for mobile device testing, application installation and technical assistance for issues experienced by end users post deployment. Monitoring & Evaluation officers are responsible for monitoring project indicators performance, impact evaluation, data analysis and reporting. They interact with CHT implementations at the design and support stages. - Researchers - they include Data Scientists, UX researchers and research scientists. They integrate research aspects such as implementation research into the project cycle to test hypothesis. They are involved through out the project cycle. diff --git a/content/en/building/integrations/android.md b/content/en/building/integrations/android.md index 5ce4a1d681..d3f1e6ef54 100644 --- a/content/en/building/integrations/android.md +++ b/content/en/building/integrations/android.md @@ -22,7 +22,7 @@ The [CHT Android application](https://github.com/medic/cht-android) can be launc When the user clicks on a link to a CHT instance from an SMS, email, WhatsApp, or any other app, Android will prompt the user to choose whether to open the URL in the Android app or the browser. If a CHT app is not installed then the URL will be opened in the browser. -The prompt may look different depending on the version of Android being used. Up to Android 11, users can choose "Always" to skip this prompt in the future. Starting with Android 12, users will be promped to associate the CHT instance's domain with the Android app. Alternatively, a CHT instance can be configured to have its links automatically verified for the associated Android App (with no user action required). See the docs on [Android App Links verification]({{< ref "building/branding/android#android-app-links-verification" >}}) for more information. +The prompt may look different depending on the version of Android being used. Up to Android 11, users can choose "Always" to skip this prompt in the future. Starting with Android 12, users will be promped to associate the CHT instance's domain with the Android app. Alternatively, a CHT instance can be configured to have its links automatically verified for the associated Android App (with no user action required). See the docs on [Android App Links verification](/building/branding/android#android-app-links-verification) for more information. ## Using an intent diff --git a/content/en/building/integrations/custom.md b/content/en/building/integrations/custom.md index b1587dab57..bec980125f 100644 --- a/content/en/building/integrations/custom.md +++ b/content/en/building/integrations/custom.md @@ -29,7 +29,7 @@ Below are a few example integration use cases: 3. **Contact Tracing**: Similar to Lost to Follow-Up, the EMR generates a list of contacts to be followed up with and this is sent to the CHT so that a tracer can call those contacts to see if they have symptoms. 4. **Interactive Messaging**: Integrate with a messaging platform (such as RapidPro) to allow community members to initiate self-screening assessments, which can then be sent to the CHT for follow-up by a healthworker. -As you design your use cases, creating a [sequence diagram](https://www.websequencediagrams.com/) will be helpful in illustrating what the flow will look like. [Here]({{< ref "building/integrations/rapidpro#sequence-diagrams" >}}) is an example sequence diagram for an integration use case with RapidPro. +As you design your use cases, creating a [sequence diagram](https://www.websequencediagrams.com/) will be helpful in illustrating what the flow will look like. [Here](/building/integrations/rapidpro#sequence-diagrams) is an example sequence diagram for an integration use case with RapidPro. ## Integration Design Patterns @@ -45,7 +45,7 @@ There are a number of different interactions that may occur between digital heal ## Sending data to other systems -Using the [outbound push]({{< ref "building/reference/app-settings/outbound" >}}) feature, you can configure the CHT to send data to another system. Before starting, you'll want to make sure you understand the APIs of the destination system and have login credentials with adequate privileges. +Using the [outbound push](/building/reference/app-settings/outbound) feature, you can configure the CHT to send data to another system. Before starting, you'll want to make sure you understand the APIs of the destination system and have login credentials with adequate privileges. To send data to other systems from the CHT, you will need to do the following: @@ -56,28 +56,28 @@ To send data to other systems from the CHT, you will need to do the following: 5. Set up credentials for the destination system ### Enable outbound -[Enable]({{< ref "building/reference/app-settings/outbound#configuration" >}}) the `mark_for_outbound` transition in `app_settings`. +[Enable](/building/reference/app-settings/outbound#configuration) the `mark_for_outbound` transition in `app_settings`. ### When data is sent -Whenever a document is changed (such as submitting a form, creating a new contact, or editing an existing one) you can configure outbound to send data to another system. The `relevant_to` [property]({{< ref "building/reference/app-settings/outbound#relevant_to" >}}) in the outbound configuration is used to identify which activities will trigger the sending of data. +Whenever a document is changed (such as submitting a form, creating a new contact, or editing an existing one) you can configure outbound to send data to another system. The `relevant_to` [property](/building/reference/app-settings/outbound#relevant_to) in the outbound configuration is used to identify which activities will trigger the sending of data. > [!TIP] > Send data to the EMR whenever a CHW submits an `assessment` form where `referral = true`. ### Where data is sent -The `destination` [property]({{< ref "building/reference/app-settings/outbound#destination" >}}) in the outbound configuration is used to specify *where* to send data. This will normally be the API endpoint of the destination system or interoperabiliy layer. +The `destination` [property](/building/reference/app-settings/outbound#destination) in the outbound configuration is used to specify *where* to send data. This will normally be the API endpoint of the destination system or interoperabiliy layer. > [!TIP] > Send data to the `/api/v1/referral` endpoint in the destination system. ### What data is sent -You configure *what* data is sent using the `mapping` [property]({{< ref "building/reference/app-settings/outbound#mapping" >}}). You will map data from the CHT to the format required by the destination API endpoint. +You configure *what* data is sent using the `mapping` [property](/building/reference/app-settings/outbound#mapping). You will map data from the CHT to the format required by the destination API endpoint. > [!TIP] > Map the `contact.name` field in the CHT to the `patient.name` field in the EMR. ### Authentication -Credentials for the destination system are [stored in CouchdDB]({{< ref "building/reference/app-settings/outbound#credentials" >}}). You will need to set this up before you can test your configuration. +Credentials for the destination system are [stored in CouchdDB](/building/reference/app-settings/outbound#credentials). You will need to set this up before you can test your configuration. ## Requests from other systems The CHT has a complete RESTful API that other systems can utilize to interact with data in the CHT. @@ -92,12 +92,12 @@ The CHT has a number of different API endpoints that can be used to look up data > [!IMPORTANT] > Example 1: You have a patient's phone number and you want to look up more information about that patient, such as who their CHW is or what Catchment Area they live in. -You can use the `contacts_by_phone` [endpoint]({{< ref "building/reference/api#get-apiv1contacts-by-phone" >}}) will return the fully hydrated contact information for those patients. +You can use the `contacts_by_phone` [endpoint](/building/reference/api#get-apiv1contacts-by-phone) will return the fully hydrated contact information for those patients. > [!IMPORTANT] > Example 2: You just have the internal UUID of a particular contact but want to get the complete information available for that contact. -You can use the `hydrate` [endpoint]({{< ref "building/reference/api#get-apiv1hydrate" >}}) to obtain this information. to look up the complete information for that contact. +You can use the `hydrate` [endpoint](/building/reference/api#get-apiv1hydrate) to obtain this information. to look up the complete information for that contact. ### POST data to the CHT The CHT API also allows you to POST data. Using these endpoints, you can create new records in your CHT API. You can store activities that took place in another system on that contact's profile in the CHT, and even create tasks for CHWs in the CHT based on activities that took place in the other system. @@ -105,9 +105,9 @@ The CHT API also allows you to POST data. Using these endpoints, you can create > [!IMPORTANT] > Example 1: You use RapidPro to send daily quarantine follow-up messages to a patient. You want to store the patient's responses to those messages on their profile in the CHT. -You can do this by submitting a JSON Form to the records [endpoint]({{< ref "building/reference/api#post-apiv2records" >}}). +You can do this by submitting a JSON Form to the records [endpoint](/building/reference/api#post-apiv2records). > [!IMPORTANT] > Example 2: Continuing from Example 1, create a task for a CHW in the CHT whenever a patient responds that they have developed symptoms. -You would do this by simply configuring a [task]({{< ref "building/tasks" >}}) to be generated based on criteria available in the report that was created in Example 1. +You would do this by simply configuring a [task](/building/tasks) to be generated based on criteria available in the report that was created in Example 1. diff --git a/content/en/building/integrations/dhis2.md b/content/en/building/integrations/dhis2.md index ed2c32ca4c..9c0bcadd89 100644 --- a/content/en/building/integrations/dhis2.md +++ b/content/en/building/integrations/dhis2.md @@ -30,7 +30,7 @@ The CHT Core Framework supports integrations with DHIS2 in a variety of ways: 6. Exposing an API for DHIS2 app developers to pull aggregate data from CHT Core 7. Receiving data from DHIS2 -Sending patient, event, and pre-aggregated data can be achieved using the [Outbound push]({{< ref "building/reference/app-settings/outbound" >}}) feature. Receiving data from DHIS2 can be achieved using the [CHT Core Web API](https://github.com/medic/cht-core/tree/master/api). +Sending patient, event, and pre-aggregated data can be achieved using the [Outbound push](/building/reference/app-settings/outbound) feature. Receiving data from DHIS2 can be achieved using the [CHT Core Web API](https://github.com/medic/cht-core/tree/master/api). Aggregating data across multiple health workers requires a somewhat specific workflow and was designed with three key user personas in mind. The aggregate workflow is described in more detail below. diff --git a/content/en/building/integrations/openmrs.md b/content/en/building/integrations/openmrs.md index 0f422aa6c3..59857ea4c9 100644 --- a/content/en/building/integrations/openmrs.md +++ b/content/en/building/integrations/openmrs.md @@ -16,7 +16,7 @@ aliases: [OpenMRS](https://openmrs.org) is an open source electronic medical record system used in dozens of countries. Integrating CHT apps with OpenMRS can open up opportunities to improve health outcomes for patients by promoting better coordination of care. For example, referrals by CHWs in the community can be sent electronically to health facilities using OpenMRS so that nurses and clinicians can prepare for their visit and have full access to the assessment done by a CHW. -Integrating CHT apps with OpenMRS can be achieved by following [this guide]({{< ref "building/integrations/openmrs" >}}), which leverages the [OpenMRS REST API](https://rest.openmrs.org). +Integrating CHT apps with OpenMRS can be achieved by following [this guide](/building/integrations/openmrs), which leverages the [OpenMRS REST API](https://rest.openmrs.org). ## Overview @@ -27,7 +27,7 @@ The CHT Core Framework supports integrations with OpenMRS in a variety of ways: 3. Exposing an API for OpenMRS developers to pull data from CHT Core 4. Receiving data from OpenMRS -Sending patients, patient contacts, and reports data can be achieved using the [Outbound push]({{< ref "building/reference/app-settings/outbound" >}}). Receiving data from OpenMRS can be achieved using the CHT Core Web [API](https://docs.communityhealthtoolkit.org/building/reference/api/). +Sending patients, patient contacts, and reports data can be achieved using the [Outbound push](/building/reference/app-settings/outbound). Receiving data from OpenMRS can be achieved using the CHT Core Web [API](https://docs.communityhealthtoolkit.org/building/reference/api/). Common OpenMRS use cases include: @@ -41,7 +41,7 @@ As you design your usecases, bear in mind that at the heart of OpenMRS is the [C ## Getting started -The [CHT API]({{< ref "building/reference/api" >}}) and [OpenMRS API](https://rest.openmrs.org/#openmrs-rest-api) are used for integration. However, the APIs do not do data cleaning and formatting out-of-the-box. Therefore, both systems require custom solutions that ochestrate the functionality to transform exchanged data to be accepted. In the following sections, we focus more on the general procedure for setting up custom modules and services. +The [CHT API](/building/reference/api) and [OpenMRS API](https://rest.openmrs.org/#openmrs-rest-api) are used for integration. However, the APIs do not do data cleaning and formatting out-of-the-box. Therefore, both systems require custom solutions that ochestrate the functionality to transform exchanged data to be accepted. In the following sections, we focus more on the general procedure for setting up custom modules and services. ### CHT to OpenMRS @@ -139,7 +139,7 @@ cht --url=https://:@localhost --accept-self-signed-certs con ``` > [!IMPORTANT] -> Remember to setup the [Outbound push]({{< ref "building/reference/app-settings/outbound" >}}) modules to send data to OpenMRS. +> Remember to setup the [Outbound push](/building/reference/app-settings/outbound) modules to send data to OpenMRS. #### Handling the data @@ -211,8 +211,8 @@ This includes defining a scheduler and a task that will be compiling the payload The CHT API can be used to process incoming reports. For custom payloads, the [{db}/bulk_docs](https://docs.couchdb.org/en/stable/api/database/bulk-api.html#db-bulk-docs) can be utilized to save multiple payloads concurrent #### Listener script in the CHT -This is a service that would help shift information in the CHT [hierarchy]({{< ref "building/reference/app-settings/hierarchy" >}}) to support the usecases of interest. Through {db}/bulk_docs, OpenMRS posts a data record that contains data objects such as observations and contact list (if available) details. The service obtains the record, and unpacks it into a contact in CHT and parented under the correct hierarchy level based on the metadata received from OpenMRS. The script should: -1. Do patient matching to avoid duplicate details. Querying can be achieved via available endpoints such as `contacts_by_phone` [endpoint]({{< ref "building/reference/api#get-apiv1contacts-by-phone" >}}) and `hydrate` [endpoint]({{< ref "building/reference/api#get-apiv1hydrate" >}}) among others/ +This is a service that would help shift information in the CHT [hierarchy](/building/reference/app-settings/hierarchy) to support the usecases of interest. Through {db}/bulk_docs, OpenMRS posts a data record that contains data objects such as observations and contact list (if available) details. The service obtains the record, and unpacks it into a contact in CHT and parented under the correct hierarchy level based on the metadata received from OpenMRS. The script should: +1. Do patient matching to avoid duplicate details. Querying can be achieved via available endpoints such as `contacts_by_phone` [endpoint](/building/reference/api#get-apiv1contacts-by-phone) and `hydrate` [endpoint](/building/reference/api#get-apiv1hydrate) among others/ 2. If the incoming data matches what exists, update the contact found in CHT. 3. Process all reports payloads and append them to the linked contact’s profile. Note that the `` xml or JSON form has to be defined in the CHT. 4. Delete the payload that is received from OpenMRS after it is processed since it will have been used to create CHT data structures. diff --git a/content/en/building/integrations/oppia.md b/content/en/building/integrations/oppia.md index a6080bf64c..d1b6020e57 100644 --- a/content/en/building/integrations/oppia.md +++ b/content/en/building/integrations/oppia.md @@ -25,11 +25,11 @@ We provide a detailed example of the CHT<>OppiaMobile integration, including how This integration leverages the **remote onboarding, task & scheduling, and target features** of the CHT core framework with the **curated, multimedia educational content** available via OppiaMobile’s learning platform. The CHT Core Framework & OppiaMobile integration currently supports the following capabilities and features: -- [Task management]({{< ref "building/tasks" >}}) for notifications on new educational modules and software updates -- [Remote onboarding]({{< ref "reference-apps/training" >}}) to new apps, software features, and workflows when they are updated, without relying on face-to-face training +- [Task management](/building/tasks) for notifications on new educational modules and software updates +- [Remote onboarding](/reference-apps/training) to new apps, software features, and workflows when they are updated, without relying on face-to-face training - Optimized multimedia content with links to educational modules powered by OppiaMobile - Message and feedback options, to contact supervisors with questions and seek support -- [Supervisor visibility]({{< ref "building/targets/targets-overview#supervisor-view" >}}) into CHW progress for onboarding, learning, and care +- [Supervisor visibility](/building/targets/targets-overview#supervisor-view) into CHW progress for onboarding, learning, and care - Hosting options for government-led, government-owned platforms The training modules configuration consists of five main components: @@ -41,7 +41,7 @@ The training modules configuration consists of five main components: ### App Forms -The CHT application uses [XLSForms]({{< ref "building/forms/app" >}}) (app forms), which are a simplified method of setting up form configurations using Excel (or Libre Office Calc, Google sheets, etc). The forms contain the questions/content that the user will interact with, including [web links](https://oppiamobile.readthedocs.io/en/latest/implementers/integration/launch_from_other_app.html) that enable the users to navigate from the CHT application to a specific course in OppiaMobile. App forms are typically created in the `project-folder > forms > app` directory of a project. If the content requires a user to access any form of media, then a media folder for the specific form is created and named after the form. For example, to add video content for a form module_one.xlsx, save the video file to the following directory: `project-folder > forms > app > module_one-media > video`. Once the forms are set up with content, the forms are converted to XForms, which are in xml format. To limit access of App Forms to certain contacts, an App Forms must have a properties file, which defines when and for whom certain forms should be accessed. Once configured, the forms are uploaded to an instance using the CHT configurer with the following commands, which upload specific forms and all forms respectively: +The CHT application uses [XLSForms](/building/forms/app) (app forms), which are a simplified method of setting up form configurations using Excel (or Libre Office Calc, Google sheets, etc). The forms contain the questions/content that the user will interact with, including [web links](https://oppiamobile.readthedocs.io/en/latest/implementers/integration/launch_from_other_app.html) that enable the users to navigate from the CHT application to a specific course in OppiaMobile. App forms are typically created in the `project-folder > forms > app` directory of a project. If the content requires a user to access any form of media, then a media folder for the specific form is created and named after the form. For example, to add video content for a form module_one.xlsx, save the video file to the following directory: `project-folder > forms > app > module_one-media > video`. Once the forms are set up with content, the forms are converted to XForms, which are in xml format. To limit access of App Forms to certain contacts, an App Forms must have a properties file, which defines when and for whom certain forms should be accessed. Once configured, the forms are uploaded to an instance using the CHT configurer with the following commands, which upload specific forms and all forms respectively: ``` cht --instance= convert-app-forms upload-app-forms -- @@ -79,7 +79,7 @@ This image shows the outcome of the button configuration: ### Tasks -[Tasks]({{< ref "building/tasks/tasks-js" >}}) are a set of actions available to users from the task tab. Selecting a task opens up a specific form that completes a workflow. Tasks are available within a given timeframe, after which they expire and the user is unable to view or do them. Tasks are defined as an array of objects in a tasks.js file under the project folder, with each task following the task schema. The required properties of a task include: +[Tasks](/building/tasks/tasks-js) are a set of actions available to users from the task tab. Selecting a task opens up a specific form that completes a workflow. Tasks are available within a given timeframe, after which they expire and the user is unable to view or do them. Tasks are defined as an array of objects in a tasks.js file under the project folder, with each task following the task schema. The required properties of a task include: - Name - unique identifier of the task; - Title - displays the workflow to be completed for a contact; @@ -122,7 +122,7 @@ The code snippet below illustrates an example of a task configured for the educa ### Targets -The users also have access to [targets]({{< ref "building/targets/targets-js" >}}). Targets are a visual representation of the progress and goals of the user. These are app analytics accessed through the targets tab, where the user is able to view how many modules they have completed. Similar to tasks, targets are defined as an array of objects in a targets.js file under the project folder, with each target following the targets schema. The required properties of a target object include: +The users also have access to [targets](/building/targets/targets-js). Targets are a visual representation of the progress and goals of the user. These are app analytics accessed through the targets tab, where the user is able to view how many modules they have completed. Similar to tasks, targets are defined as an array of objects in a targets.js file under the project folder, with each target following the targets schema. The required properties of a target object include: - Id - unique identifier of the target; - Translation_key - title displayed for the widget; @@ -184,7 +184,7 @@ Below is a code snippet for a target configured for the educational modules: ### Contact Summary -In addition to targets, the user is able to see which specific modules they have completed, and view upcoming tasks and other general information on their profile. The section containing this information is known as the [contact summary]({{< ref "building/contact-summary/contact-summary-templated" >}}). The contact summary has 3 main outputs: cards, fields, and context. Contact summary is defined in the `contact-summary.templated.js` file under the project folder. +In addition to targets, the user is able to see which specific modules they have completed, and view upcoming tasks and other general information on their profile. The section containing this information is known as the [contact summary](/building/contact-summary/contact-summary-templated). The contact summary has 3 main outputs: cards, fields, and context. Contact summary is defined in the `contact-summary.templated.js` file under the project folder. Cards are an array of objects which can be customized to group information viewed on a contact’s profile. The required properties of a card include: diff --git a/content/en/building/integrations/rapidpro.md b/content/en/building/integrations/rapidpro.md index 438cae091a..e6f81a9ead 100644 --- a/content/en/building/integrations/rapidpro.md +++ b/content/en/building/integrations/rapidpro.md @@ -20,22 +20,22 @@ To learn more about the platform, check out RapidPro on [GitHub](https://rapidpr Coming up with a design to accommodate user needs requires a detailed understanding of the capabilities of both systems and conceptually where it makes sense to introduce interactions between them. Below we introduce some of the key concepts in RapidPro, but to learn more you can have a look at their [documentation](https://rapidpro.github.io/rapidpro/docs/). ## Overview -CHT-based [SMS workflows]({{< ref "building/workflows/workflows-overview#sms-messaging" >}}) can be configured to support registering of new patients or pregnancies, recording outcomes of visits, confirmation via auto-responses, and scheduling reminders. Some projects are designed entirely around SMS workflows. The CHT also supports person to person SMS [messaging]({{< ref "building/messaging" >}}) from the Messages tab. +CHT-based [SMS workflows](/building/workflows/workflows-overview#sms-messaging) can be configured to support registering of new patients or pregnancies, recording outcomes of visits, confirmation via auto-responses, and scheduling reminders. Some projects are designed entirely around SMS workflows. The CHT also supports person to person SMS [messaging](/building/messaging) from the Messages tab. For more complex messaging workflows or to utilize other messaging platforms, you can design workflows that leverage the functionality of RapidPro and the CHT together. This enables semi-automated, direct to patient approaches to health assessments and care coordination at the community level. ## Workflows -Integrated RapidPro/CHT workflows are very flexible and leverage the full functionality of each application; You configure RapidPro directly in RapidPro, and configure the CHT in the CHT and the two systems communicate with each other through APIs and [Outbound push]({{< ref "building/reference/app-settings/outbound" >}}). With this architecture, you are not limited to a subset of functionality within either application. +Integrated RapidPro/CHT workflows are very flexible and leverage the full functionality of each application; You configure RapidPro directly in RapidPro, and configure the CHT in the CHT and the two systems communicate with each other through APIs and [Outbound push](/building/reference/app-settings/outbound). With this architecture, you are not limited to a subset of functionality within either application. -A simple RapidPro/CHT integration might include triggering an interactive SMS messaging flow in RapidPro whenever a new patient is registered in the CHT and then storing the responses of that messaging flow in the CHT. You could then conditionally trigger a [Task]({{< ref "building/tasks" >}}) for a health worker in the CHT based on the patient responses from the RapidPro flow. +A simple RapidPro/CHT integration might include triggering an interactive SMS messaging flow in RapidPro whenever a new patient is registered in the CHT and then storing the responses of that messaging flow in the CHT. You could then conditionally trigger a [Task](/building/tasks) for a health worker in the CHT based on the patient responses from the RapidPro flow. App builders have built and deployed a number of interactive messaging workflows that integrate RapidPro and the CHT already, see below for a few examples. ### Contact Tracing -The [COVID-19 Contact Tracing app]({{< ref "reference-apps/contact-tracing#workflow-example" >}}) uses RapidPro to send messages to quarantined COVID-19 patients. Messages are sent to the patients daily asking whether or not they developed new symptoms. If so, a health worker will be notified by SMS and receive a CHT task. All responses to the RapidPro workflow are recorded in the CHT and can be queried in analytics. +The [COVID-19 Contact Tracing app](/reference-apps/contact-tracing#workflow-example) uses RapidPro to send messages to quarantined COVID-19 patients. Messages are sent to the patients daily asking whether or not they developed new symptoms. If so, a health worker will be notified by SMS and receive a CHT task. All responses to the RapidPro workflow are recorded in the CHT and can be queried in analytics. ### Remote Training -The [Remote Training by SMS app]({{< ref "reference-apps/training#remote-training-by-sms" >}}) uses RapidPro to train health workers on Antenatal Care in the language of their choice. If the health worker answers a training question incorrectly, a task can be created for their supervisor to follow up with them. +The [Remote Training by SMS app](/reference-apps/training#remote-training-by-sms) uses RapidPro to train health workers on Antenatal Care in the language of their choice. If the health worker answers a training question incorrectly, a task can be created for their supervisor to follow up with them. ### CHW Symptom and Mental Health Checks The [CHW Symptom and Mental Health Checks app](https://docs.google.com/document/d/19F6vOCNFKQnSyREiaBnryUmre20s5QZzYe0hWuWn-0k/edit) is used to proactively check in with health workers to screen for COVID-19 symptoms and/or the need for psychosocial counseling. @@ -106,7 +106,7 @@ The information below focuses on specific interactions between RapidPro and the ### Create RapidPro user in CHT -For RapidPro to communicate with the CHT, you need to create a [User]({{< ref "building/users" >}}) in the CHT that will be used by RapidPro when calling the CHT’s APIs. This can be done from the [App Management]({{< ref "building/admin/" >}}) page in the CHT. When adding the user in the CHT, be sure to select the `Gateway - Limited access user for Medic Gateway` [Role]({{< ref "building/users#roles" >}}). +For RapidPro to communicate with the CHT, you need to create a [User](/building/users) in the CHT that will be used by RapidPro when calling the CHT’s APIs. This can be done from the [App Management](/building/admin/) page in the CHT. When adding the user in the CHT, be sure to select the `Gateway - Limited access user for Medic Gateway` [Role](/building/users#roles). ### Globals @@ -120,7 +120,7 @@ Once you have configured a Global value, you can easily use it in your flows lik ### Start RapidPro Flow from CHT -One of the most common activities you'll want to do is trigger a Flow in RapidPro based on something that occurred in the CHT. For example... whenever a specific form is submitted in the CHT with some conditional value, start a flow in RapidPro. To do this, you will use the [Outbound]({{< ref "building/reference/app-settings/outbound" >}}) feature in the CHT, invoking the [Flow Starts Endpoint](https://rapidpro.io/api/v2/explorer/) in RapidPro. +One of the most common activities you'll want to do is trigger a Flow in RapidPro based on something that occurred in the CHT. For example... whenever a specific form is submitted in the CHT with some conditional value, start a flow in RapidPro. To do this, you will use the [Outbound](/building/reference/app-settings/outbound) feature in the CHT, invoking the [Flow Starts Endpoint](https://rapidpro.io/api/v2/explorer/) in RapidPro. Below is an example `outbound` config in the CHT called `textit-self-quarantine` that will trigger a flow in RapidPro whenever a `covid_trace_follow_up` form is submitted in the CHT where `symptom = no`. It will also pass an extra date value for `self_quarantine_enrollment`. @@ -162,9 +162,9 @@ Once a user has completed a Flow in RapidPro, it is likely you will want to reco |Step |Application |Config step | |-----|--|--| -|1|CHT| Configure a [JSON Form]({{< ref "building/reference/app-settings/forms" >}}) that includes the fields from RapidPro you want to send to the CHT.| +|1|CHT| Configure a [JSON Form](/building/reference/app-settings/forms) that includes the fields from RapidPro you want to send to the CHT.| |2|RapidPro|Add a *Call a Webhook* node.| -|3|RapidPro|`POST` to the [records endpoint]({{< ref "building/reference/api#post-apiv2records" >}}) in the CHT. If you used the Global value mentioned above, the POST will look something like `@globals.api/v2/records`.| +|3|RapidPro|`POST` to the [records endpoint](/building/reference/api#post-apiv2records) in the CHT. If you used the Global value mentioned above, the POST will look something like `@globals.api/v2/records`.| |4|RapidPro|Set a `Result Name`| |5|RapidPro|Configure HTTP Headers to be `Content-Type` -> `application/json`| |6|RapidPro|Configure the `POST Body` (see example below)| @@ -174,7 +174,7 @@ Once a user has completed a Flow in RapidPro, it is likely you will want to reco ### Look up CHT data from RapidPro -Another common action you will likely need to perform in RapidPro is getting information from the CHT about a user or patient based on their phone number. You can use the [contacts-by-phone]({{< ref "building/reference/api#contacts-by-phone" >}}) API to get fully hydrated contacts associated to that phone number. +Another common action you will likely need to perform in RapidPro is getting information from the CHT about a user or patient based on their phone number. You can use the [contacts-by-phone](/building/reference/api#contacts-by-phone) API to get fully hydrated contacts associated to that phone number. diff --git a/content/en/building/interoperability/cht-config.md b/content/en/building/interoperability/cht-config.md index 52dd91f8e9..654fb8cab3 100644 --- a/content/en/building/interoperability/cht-config.md +++ b/content/en/building/interoperability/cht-config.md @@ -23,7 +23,7 @@ You can see more details of the tool [in the cht-interoperability repository](ht 4. Sending health information represented as [Encounters](https://build.fhir.org/encounter.html) with [Observations](https://build.fhir.org/observation.html) from interoperating systems to CHT applications. ## Sending Data -When sending data to an interoperating system, [outbound push]({{< ref "building/reference/app-settings/outbound" >}}) is used to configure which documents should be sent and at what point. +When sending data to an interoperating system, [outbound push](/building/reference/app-settings/outbound) is used to configure which documents should be sent and at what point. A [mediator](http://openhim.org/docs/configuration/mediators/) then converts these documents to FHIR resources and orchestrates sending them to interoperating systems. The default mediator makes any resources sent to it queryable via a FHIR API using [HAPI](https://hapifhir.io/). diff --git a/content/en/building/interoperability/ltfu.md b/content/en/building/interoperability/ltfu.md index eee81e54db..45635fa564 100644 --- a/content/en/building/interoperability/ltfu.md +++ b/content/en/building/interoperability/ltfu.md @@ -28,7 +28,7 @@ The section includes placeholders for URLs. Replacing these placeholders with th ## Steps The following steps assume you have running OpenHIM and CHT instances you successfully logged into. -See the [OpenHIM guide]({{< ref "building/interoperability/openhim" >}}) for instructions to set up a local development instance of OpenHIM. +See the [OpenHIM guide](/building/interoperability/openhim) for instructions to set up a local development instance of OpenHIM. 1. Create an **Endpoint** and an **Organization** @@ -41,7 +41,7 @@ See the [OpenHIM guide]({{< ref "building/interoperability/openhim" >}}) for ins 2. Create a **Patient** - 1. **CHT** - Log in to the CHT platform using the credentials for the `chw` user. If the `chw` user does not already exist, you can [create one]({{< ref "building/contact-management/contact-and-users-1#4-create-the-chw-user" >}}). + 1. **CHT** - Log in to the CHT platform using the credentials for the `chw` user. If the `chw` user does not already exist, you can [create one](/building/contact-management/contact-and-users-1#4-create-the-chw-user). 1. **CHT** - Navigate to the `People` tab in the CHT dashboard. From there, select a Facility where you want to create a new `Person`. Click on the `New Person` button and fill in the required details for the Person. Make sure to select `Patient` as the `Person`'s role for this flow. 1. **CHT** - Once you have created the new `Person`, you need to retrieve their unique identifier from the browser's URL. You can do this by copying the alphanumeric string that appears after `person/` in the URL. Keep this identifier safe as you will need it for the next steps. 1. **OpenHIM Admin Console** - To verify that the `Patient` creation was successful, navigate to the `Transaction Log` in the OpenHIM Admin Console. You should see two successful API calls recorded in the log, one to `/mediator/patient/` and one to `/fhir/Patient/`. diff --git a/content/en/building/interoperability/openhim.md b/content/en/building/interoperability/openhim.md index 00f43105c3..0218a5e509 100644 --- a/content/en/building/interoperability/openhim.md +++ b/content/en/building/interoperability/openhim.md @@ -38,11 +38,11 @@ mediator_a -- Requestfa:fa-arrow-right --- openhim mediator_b -- Channelfa:fa-arrow-left --- openhim ``` -CHT Interoperability uses OpenHIM as the middleware component with [Mediators](http://openhim.org/docs/configuration/mediators/) to do the conversion. [Outbound Push]({{< ref "building/reference/app-settings/outbound" >}}) is configured to make a request to the middleware when relevant documents are created or modified in the CHT. A Mediator then creates a FHIR resource which is then routed to OpenHIM. OpenHIM routes the resource to any other configured systems. +CHT Interoperability uses OpenHIM as the middleware component with [Mediators](http://openhim.org/docs/configuration/mediators/) to do the conversion. [Outbound Push](/building/reference/app-settings/outbound) is configured to make a request to the middleware when relevant documents are created or modified in the CHT. A Mediator then creates a FHIR resource which is then routed to OpenHIM. OpenHIM routes the resource to any other configured systems. -Conversely, to bring data into the CHT, OpenHIM is configured to route the updated resource to the Mediator, which then calls the relevant [CHT APIs]({{< ref "building/reference/api" >}}) to update the document in the CHT database. This will then be replicated to users’ devices as per usual. +Conversely, to bring data into the CHT, OpenHIM is configured to route the updated resource to the Mediator, which then calls the relevant [CHT APIs](/building/reference/api) to update the document in the CHT database. This will then be replicated to users’ devices as per usual. -See more information on the [CHT interoperability page]({{< ref "building/interoperability/overview" >}}). +See more information on the [CHT interoperability page](/building/interoperability/overview). ### Prerequisites @@ -52,7 +52,7 @@ See more information on the [CHT interoperability page]({{< ref "building/intero > [!NOTE] -> Users getting errors when running the following installation steps, see the [Troubleshooting guide]({{< ref "#troubleshooting" >}}). +> Users getting errors when running the following installation steps, see the [Troubleshooting guide](/#troubleshooting). ### Install & First Time Run @@ -98,8 +98,8 @@ curl -X GET localhost:5001/mediator/openmrs/sync -H "Authorization: Basic $(echo The following steps apply when running CHT via the Docker setup provided in the cht-interoperability repository: 1. CHT can be accessed via [http://localhost:5988](http://localhost:5988), and the credentials are `admin`/`password`. -2. Create a new user in the CHT instance with the username `interop-client` using these [instructions]({{< ref "building/contact-management/contact-and-users-1#4-create-the-chw-user" >}}). For the role you can select `Data entry` and `Analytics` roles. Note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452). -3. Securely save the `interop-client` user's password to the database using the instructions [here]({{< ref "building/reference/api#credentials" >}}). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curl request is below: +2. Create a new user in the CHT instance with the username `interop-client` using these [instructions](/building/contact-management/contact-and-users-1#4-create-the-chw-user). For the role you can select `Data entry` and `Analytics` roles. Note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452). +3. Securely save the `interop-client` user's password to the database using the instructions [here](/building/reference/api#credentials). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curl request is below: ```bash curl -X PUT -H "Content-Type: text/plain" http://admin:password@localhost:5988/api/v1/credentials/openhim1 -d 'interop-password' @@ -111,9 +111,9 @@ The following steps apply when running CHT locally in development mode and when #### CHT Development Environment -1. Set up a local CHT instance using [these instructions]({{< ref "building/local-setup" >}}). -2. Create a new user in the CHT instance with the username `interop-client` using these [instructions]({{< ref "building/contact-management/contact-and-users-1#4-create-the-chw-user" >}}). For the role you can select `Data entry` and `Analytics` roles. Note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452). -3. Securely save the `interop-client` user's password to the database using the instructions [here]({{< ref "building/reference/api#credentials" >}}). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curls request is below: +1. Set up a local CHT instance using [these instructions](/building/local-setup). +2. Create a new user in the CHT instance with the username `interop-client` using these [instructions](/building/contact-management/contact-and-users-1#4-create-the-chw-user). For the role you can select `Data entry` and `Analytics` roles. Note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452). +3. Securely save the `interop-client` user's password to the database using the instructions [here](/building/reference/api#credentials). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curls request is below: ```bash curl -X PUT -H "Content-Type: text/plain" http://medic:password@localhost:5988/api/v1/credentials/openhim1 -d 'interop-password' diff --git a/content/en/building/interoperability/openmrs.md b/content/en/building/interoperability/openmrs.md index 7ac423f22a..3b51767e4d 100644 --- a/content/en/building/interoperability/openmrs.md +++ b/content/en/building/interoperability/openmrs.md @@ -14,7 +14,7 @@ aliases: [OpenMRS](https://openmrs.org) is an open-source electronic medical record system used in dozens of countries. Data exchange between CHT apps and OpenMRS can open up opportunities to improve health outcomes for patients by promoting better coordination of care. For example, referrals by CHWs in the community can be sent electronically to health facilities using OpenMRS so that nurses and clinicians can prepare for their visit and have full access to the assessment done by a CHW. -CHT apps can exchange data with OpenMRS using the CHT's [Interoperability Tools]({{< ref "building/interoperability/openhim" >}}) and following the guidance in the [Building interoperability with FHIR APIs documentation]({{< ref "building/interoperability/cht-config" >}}). +CHT apps can exchange data with OpenMRS using the CHT's [Interoperability Tools](/building/interoperability/openhim) and following the guidance in the [Building interoperability with FHIR APIs documentation](/building/interoperability/cht-config). ## Overview @@ -25,7 +25,7 @@ The steps to create an OpenMRS interoperability workflow are: 1. Profile the workflow in terms of what data needs to be exchanged between OpenMRS and the CHT application. 1. Set up a test environment including an OpenMRS instance, a CHT instance, and OpenHIM. The [interoperability project](https://github.com/medic/cht-interoperability) has docker compose files so that you can set this up locally by running `./startup.sh up-openmrs` in the interoperability project. 1. Create or find [concepts](https://guide.openmrs.org/configuration/managing-concepts-and-metadata/) in OpenMRS that represent any data that needs to be exchanged. -1. [Configure outbound push and forms]({{< ref "building/interoperability/cht-config" >}}) in the CHT application to match the interoperability workflow. +1. [Configure outbound push and forms](/building/interoperability/cht-config) in the CHT application to match the interoperability workflow. 1. Test and debug any configuration issues in the test environment. 1. Once the configuration is confirmed to be working as expected, start deploying to production by uploading the CHT configuration to production. 1. Add any OpenMRS concepts or forms to production. @@ -41,11 +41,11 @@ The first step is to profile the workflow. ## Configuring CHT And OpenMRS -Depending on what data needs to be exchanged, [outbound push]({{< ref "building/reference/app-settings/outbound" >}}) configurations and JSON forms need to be added to CHT. +Depending on what data needs to be exchanged, [outbound push](/building/reference/app-settings/outbound) configurations and JSON forms need to be added to CHT. ### Sending patients CHT->OpenMRS -When sending patient data to OpenMRS, configure an outbound push mapping as described in the [CHT FHIR config documentation]({{< ref "building/interoperability/cht-config#outbound-patients" >}}). +When sending patient data to OpenMRS, configure an outbound push mapping as described in the [CHT FHIR config documentation](/building/interoperability/cht-config#outbound-patients). Patients synced to OpenMRS will have two new [identifier types](https://guide.openmrs.org/getting-started/openmrs-information-model/#patient-identifier): `CHT Document Id`, the uuid of the document that is sent, and `CHT Patient ID`, if there is a `patient_id` field on the patient document. These identifier types are created automatically when the OpenMRS Channel is registered. @@ -130,7 +130,7 @@ curl -X GET localhost:8090/openmrs/ws/fhir2/R4/Patient/?identifier=[identifier] Any data sent from CHT to OpenMRS needs to map to a [concept](https://wiki.openmrs.org/display/docs/Concept+Dictionary+Basics) in OpenMRS. Each concept has a code which will be used to identify the concept in the CHT Application, the FHIR Server, and OpenMRS. For any fields to send to OpenMRS, first find or create matching concepts in OpenMRS. -Then, using the appropriate codes, configure an outbound push as described in the [CHT FHIR config documentation]({{< ref "building/interoperability/cht-config#outbound-reports" >}}). +Then, using the appropriate codes, configure an outbound push as described in the [CHT FHIR config documentation](/building/interoperability/cht-config#outbound-reports). In OpenMRS, all form submissions are represented as `Home Visit` encounter types, with a `Visit Note` encounter. Any fields in the outbound push config are converted to FHIR observations, which are linked to the `Visit Note`. @@ -179,7 +179,7 @@ curl -X GET localhost:8090/openmrs/ws/fhir2/R4/Encounter/?identifier=[identifier ## Starting the interop project -Once the CHT and OpenMRS configs are ready, set up OpenHIM and install the mediators by following the instructions [here]({{< ref "building/interoperability/openhim" >}}). +Once the CHT and OpenMRS configs are ready, set up OpenHIM and install the mediators by following the instructions [here](/building/interoperability/openhim). Set `OPENMRS_URL`, `OPENMRS_PORT`, and `OPENMRS_HOST` in .env to configure the necessary channel automatically. | Name | Description | |---------------------------|-------------------------------------------------------------------------------------------------------------| @@ -212,7 +212,7 @@ This includes: ### Troubleshooting -In case of errors when setting up the OpenHIM project see the [Troubleshooting guide]({{< ref "building/interoperability/openhim#troubleshooting" >}}). +In case of errors when setting up the OpenHIM project see the [Troubleshooting guide](/building/interoperability/openhim#troubleshooting). If the openhim project starts up correctly but something else does not work as expected, it can be helpful to first check the transaction log page of OpenHIM to see which requests were sent, and the request and response bodies. See the sequence diagrams above for the expected requests/responses. diff --git a/content/en/building/interoperability/overview.md b/content/en/building/interoperability/overview.md index 74321bbe47..a6dbec17ac 100644 --- a/content/en/building/interoperability/overview.md +++ b/content/en/building/interoperability/overview.md @@ -61,5 +61,5 @@ The flexibility of mediators also means the CHT is future-proof and can be confi 4. [Organization](https://build.fhir.org/organization.html) 5. [Endpoint](https://build.fhir.org/endpoint.html) -You can find additional information and instructions for setting up [cht-interoperability](https://github.com/medic/cht-interoperability) in the [dedicated guidelines]({{< ref "building/interoperability/openhim" >}}) . +You can find additional information and instructions for setting up [cht-interoperability](https://github.com/medic/cht-interoperability) in the [dedicated guidelines](/building/interoperability/openhim) . diff --git a/content/en/building/local-setup.md b/content/en/building/local-setup.md index fe6125b2f8..10ecf68e6a 100644 --- a/content/en/building/local-setup.md +++ b/content/en/building/local-setup.md @@ -21,7 +21,7 @@ By the end of the tutorial you should be able to: ## Brief Overview of Key Concepts -The *CHT Core Framework* makes it faster to build full-featured, scalable digital health apps by providing a foundation developers can build on. These apps can support most languages, are [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}), and work on basic phones (via SMS), smartphones, tablets, and computers. +The *CHT Core Framework* makes it faster to build full-featured, scalable digital health apps by providing a foundation developers can build on. These apps can support most languages, are [Offline-First](/technical-overview/concepts/offline-first), and work on basic phones (via SMS), smartphones, tablets, and computers. [*CHT Project Configurer*](https://github.com/medic/cht-conf) also known as ***cht-conf*** is a command-line interface tool to manage and configure CHT apps. @@ -199,7 +199,7 @@ This CHT instance is empty and has no data in it. While you're free to explore a ### Upload Test Data -By default, the CHT will have the [Maternal & Newborn Health Reference Application]({{< ref "reference-apps/maternal-newborn" >}}) installed. To upload demo data you can use `cht-conf`: +By default, the CHT will have the [Maternal & Newborn Health Reference Application](/reference-apps/maternal-newborn) installed. To upload demo data you can use `cht-conf`: {{< figure src="test.data.png" link="test.data.png" class="right col-3 col-lg-6" >}} diff --git a/content/en/building/login.md b/content/en/building/login.md index 9400db7c09..85fc5e71d8 100644 --- a/content/en/building/login.md +++ b/content/en/building/login.md @@ -65,6 +65,6 @@ With token login, the password is never known by the admin or the user because t ## Single Sign-On (OIDC Login) -The CHT supports Single Sign-On (SSO) via integration with an external authentication server. When [configured]({{< ref "building/reference/app-settings/oidc_provider" >}}), users can authenticate with their SSO credentials instead of needing a CHT-specific username and password. +The CHT supports Single Sign-On (SSO) via integration with an external authentication server. When [configured](/building/reference/app-settings/oidc_provider), users can authenticate with their SSO credentials instead of needing a CHT-specific username and password. {{< see-also page="/hosting/sso" >}} diff --git a/content/en/building/messaging/gateways/gateway/configuration.md b/content/en/building/messaging/gateways/gateway/configuration.md index c9c8d8f576..a006b003ec 100644 --- a/content/en/building/messaging/gateways/gateway/configuration.md +++ b/content/en/building/messaging/gateways/gateway/configuration.md @@ -17,7 +17,7 @@ CHT gateway supports Android 4.1 and above. To have it up and fully working, fol ### Step 1 -Install the latest APK from the [releases page](https://github.com/medic/cht-gateway/releases) in the `cht-gateway` repo. This APK is not in the Play Store, you will need to side-load it [as is done with CHT Android]({{< ref "building/branding/publishing#side-loading" >}}). +Install the latest APK from the [releases page](https://github.com/medic/cht-gateway/releases) in the `cht-gateway` repo. This APK is not in the Play Store, you will need to side-load it [as is done with CHT Android](/building/branding/publishing#side-loading). ### Step 2 diff --git a/content/en/building/messaging/gateways/gateway/phones.md b/content/en/building/messaging/gateways/gateway/phones.md index d446ddef00..40efc7adca 100644 --- a/content/en/building/messaging/gateways/gateway/phones.md +++ b/content/en/building/messaging/gateways/gateway/phones.md @@ -12,7 +12,7 @@ relatedContent: > building/messaging/gateways/gateway/configuration --- -In order to use SMS workflows with the CHT you will need an SMS gateway. For reliability an SMS Aggregator, such as [Africa's Talking]({{< ref "building/messaging/gateways/africas-talking" >}}) or [RapidPro]({{< ref "building/messaging/gateways/rapidpro" >}}), is recommended. When an SMS Aggregator is not available, an Android device running [CHT Gateway](https://github.com/medic/cht-gateway) can be used to send and receive SMS in your CHT application. You may use an existing Android device and are not required to purchase a new one. However, for more reliable sending and receiving of SMS, the Android device should be in your organization’s office or facility with a consistent internet connection. +In order to use SMS workflows with the CHT you will need an SMS gateway. For reliability an SMS Aggregator, such as [Africa's Talking](/building/messaging/gateways/africas-talking) or [RapidPro](/building/messaging/gateways/rapidpro), is recommended. When an SMS Aggregator is not available, an Android device running [CHT Gateway](https://github.com/medic/cht-gateway) can be used to send and receive SMS in your CHT application. You may use an existing Android device and are not required to purchase a new one. However, for more reliable sending and receiving of SMS, the Android device should be in your organization’s office or facility with a consistent internet connection. Below is a list of recommended Android devices across a range of prices. You may find these in local mobile equipment stores as well as online through Amazon and other e-commerce sites. diff --git a/content/en/building/messaging/gateways/gateway/troubleshooting.md b/content/en/building/messaging/gateways/gateway/troubleshooting.md index f82abe0857..2d0b273b5c 100644 --- a/content/en/building/messaging/gateways/gateway/troubleshooting.md +++ b/content/en/building/messaging/gateways/gateway/troubleshooting.md @@ -48,7 +48,7 @@ cd /srv/storage/gardener/logs/ ls -lt grep api/sms medic_medic_medic-api4.log ``` -If the above steps don't yield the problem, read the [Obtaining Logs]({{< ref "community/contributing/code/troubleshooting/obtaining-logs#android-logs" >}}) page, note the make/model/android version their gateway handset is and escalate with those details to the PM/project techlead. +If the above steps don't yield the problem, read the [Obtaining Logs](/community/contributing/code/troubleshooting/obtaining-logs#android-logs) page, note the make/model/android version their gateway handset is and escalate with those details to the PM/project techlead. **Verifying the SMS Gateway via a Test Message** diff --git a/content/en/building/prerequisites.md b/content/en/building/prerequisites.md index a503c90c13..c133054851 100644 --- a/content/en/building/prerequisites.md +++ b/content/en/building/prerequisites.md @@ -14,7 +14,7 @@ aliases: There are no set prerequisites for users of CHT apps, yet the following are helpful for developing CHT applications. ## Test Instance -To build your own application using the Core Framework you will need an instance set up for testing. You can set up a local instance by [following these instructions]({{< ref "building/local-setup" >}}). +To build your own application using the Core Framework you will need an instance set up for testing. You can set up a local instance by [following these instructions](/building/local-setup). ## Build tool The build tool for applications using the Core Framework is `cht-conf`. To set it up, follow the [installation instructions](https://github.com/medic/cht-conf/blob/master/README.md). To properly use the tool you will need your application files in set locations within a folder. Once you are set up with the basic file structure you can edit the files, and rebuild the application by compiling or converting components as needed, and uploading them to your test instance. diff --git a/content/en/building/reference/_partial_cht_api.md b/content/en/building/reference/_partial_cht_api.md index f0bd8ed1b7..b0dc4ef502 100644 --- a/content/en/building/reference/_partial_cht_api.md +++ b/content/en/building/reference/_partial_cht_api.md @@ -13,8 +13,8 @@ Provides CHT-Core Framework's functions to contact summary, targets and tasks. T | -------- | --------- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | hasPermissions(permissions, userRoles, chtPermissionsSettings) | `permissions`: String or array of permission name(s).
`userRoles`: (Optional) Array of user roles. Default to the current logged in user.
`chtPermissionsSettings`: (Optional) Object of configured permissions in CHT-Core's settings. Default to the current instance's configured permissions. | Returns true if the user has the permission(s), otherwise returns false. | | hasAnyPermission(permissionsGroups, userRoles, chtPermissionsSettings) | `permissionsGroups`: Array of groups of permission name(s).
`userRoles`: (Optional) Array of user roles. Default to the current logged in user.
`chtPermissionsSettings`: (Optional) Object of configured permissions in CHT-Core's settings. Default to the current instance's configured permissions. | Returns true if the user has all the permissions of any of the provided groups, otherwise returns false. | -| getExtensionLib(name) | `name`: String of script name | Returns an executable function identified by the given name configured as [extension-libs]({{< ref "extension-libs" >}}). -| analytics.getTargetDocs() | | Returns three [target]({{< ref "technical-overview/data/db-schema#targets" >}} ) documents of the contact, calculated for the last three reporting intervals, including the current one. When viewing one of the current logged in user's associated facilities, returns the target documents for the contact associated with the current logged in user. Returns an empty array if no target documents are found (for example when viewing a contact that does not upload targets). _Introduced in v4.11.0_ | +| getExtensionLib(name) | `name`: String of script name | Returns an executable function identified by the given name configured as [extension-libs](/extension-libs). +| analytics.getTargetDocs() | | Returns three [target](/technical-overview/data/db-schema#targets) documents of the contact, calculated for the last three reporting intervals, including the current one. When viewing one of the current logged in user's associated facilities, returns the target documents for the contact associated with the current logged in user. Returns an empty array if no target documents are found (for example when viewing a contact that does not upload targets). _Introduced in v4.11.0_ | ### CHT API's code samples diff --git a/content/en/building/reference/api.md b/content/en/building/reference/api.md index db2c713c87..bad4bafc0b 100644 --- a/content/en/building/reference/api.md +++ b/content/en/building/reference/api.md @@ -14,7 +14,7 @@ aliases: } -This page covers the endpoints to use when integrating with the CHT server. If there isn't an endpoint that provides the function or data you need, direct access to the database is possible via the [CouchDB API](https://docs.couchdb.org/en/stable/api/index.html). Access to the [PostgreSQL database]({{< ref "technical-overview/data/analytics/data-flows-for-analytics" >}}) may also prove useful for data analysis. If additional endpoints would be helpful, make suggestions via a [GitHub issue](https://github.com/medic/cht-core/issues/new/choose). +This page covers the endpoints to use when integrating with the CHT server. If there isn't an endpoint that provides the function or data you need, direct access to the database is possible via the [CouchDB API](https://docs.couchdb.org/en/stable/api/index.html). Access to the [PostgreSQL database](/technical-overview/data/analytics/data-flows-for-analytics) may also prove useful for data analysis. If additional endpoints would be helpful, make suggestions via a [GitHub issue](https://github.com/medic/cht-core/issues/new/choose). {{< toc >}} @@ -2097,7 +2097,7 @@ will be undefined. | fullname | no | String | Full name | | | email | no | String | Email address | | | known | no | Boolean | Boolean to define if the user has logged in before. | | -| password_change_required | no | Boolean | Set `false` to avoid the user being prompted to [reset their password]({{< ref "building/login/#password-reset-on-first-login" >}}) the next time they log in. | 4.17.0 | +| password_change_required | no | Boolean | Set `false` to avoid the user being prompted to [reset their password](/building/login/#password-reset-on-first-login) the next time they log in. | 4.17.0 | | oidc_username | no | String | A unique username for [authenticating via OIDC](#login-by-oidc). This value must match the `email` claim returned for the user by the OIDC provider. | 4.20.0 | #### Login by SMS @@ -2139,11 +2139,11 @@ If `app_settings.app_url` is not defined, the generated token-login URL will use Introduced in 4.20.0. This feature is only compatible with cht-android version `v1.5.2` or greater. {{< /callout >}} -When [SSO Login]({{< ref "/hosting/sso" >}}) is enabled (by configuring the [`oidc_provider` settings]({{< ref "building/reference/app-settings/oidc_provider" >}})), a CHT user must be provisioned for each SSO user prior to them logging in. The CHT user's `oidc_username` property must be set to the value of the user's `email` claim from the OIDC Provider. +When [SSO Login](//hosting/sso) is enabled (by configuring the [`oidc_provider` settings](/building/reference/app-settings/oidc_provider)), a CHT user must be provisioned for each SSO user prior to them logging in. The CHT user's `oidc_username` property must be set to the value of the user's `email` claim from the OIDC Provider. Two CHT users cannot share the same `oidc_username` value. Setting the `oidc_username` property for a user will cause the user's password (in the CHT) to be set to a random value, preventing them from logging in with other authentication methods. Instead, the user must log in using the "Login with SSO" button. -When creating/editing users via the [App Management interface]({{< ref "building/admin/admin-overview" >}}), the "SSO Email Address" field is used to set the `oidc_username` property. +When creating/editing users via the [App Management interface](/building/admin/admin-overview), the "SSO Email Address" field is used to set the `oidc_username` property. (Note: it is possible to have a mixed environment where some users log in with SSO and others log in with other authentication methods. In this case, the `oidc_username` property is only set for those users who log in with SSO.) @@ -2408,7 +2408,7 @@ Create new users with a place and a contact. All users need to meet the following requirements before any of them are created: - All required fields are filled in - The password is at least 8 characters long and difficult to guess -- The phone number is valid when [`token_login`]({{< ref "building/reference/app-settings/token_login" >}}) is enabled +- The phone number is valid when [`token_login`](/building/reference/app-settings/token_login) is enabled Users are created in parallel and the creation is not aborted even if one of the users fails to be created. @@ -2630,21 +2630,21 @@ Content-Type: application/json Create new users with a place and a contact from a CSV file. -Creating users from a CSV file behaves the same as passing a JSON array of users into the [`POST /api/v1/users`]({{< ref "building/reference/api#post-apiv1users" >}}) +Creating users from a CSV file behaves the same as passing a JSON array of users into the [`POST /api/v1/users`](/building/reference/api#post-apiv1users) where a row represents a user object and a column represents a user object property. Columns with a `:excluded` suffix will be ignored, this allows providing a more user-friendly experience with autocompletion on fields or dealing with names instead of long, unreadable ids. In order to facilitate this process, we have made available a spreadsheet compatible with the `default` configuration of the CHT. [Click here](https://docs.google.com/spreadsheets/d/1yUenFP-5deQ0I9c-OYDTpbKYrkl3juv9djXoLLPoQ7Y/copy) to make a copy of the spreadsheet in Google Sheets. -[A guide]({{< ref "building/training/users-bulk-load" >}}) on how to import users with this spreadsheet from within the Admin Console is available +[A guide](/building/training/users-bulk-load) on how to import users with this spreadsheet from within the Admin Console is available in case you don't want to interact with this API yourself. #### Logging A log entry is created with each bulk import that contains the import status for each user and the import progress status that gets updated throughout the import and finalized upon completion. -These entries are saved in the [`medic-logs`]({{< ref "technical-overview/data#medic-logs" >}}) database and you can access them +These entries are saved in the [`medic-logs`](/technical-overview/data#medic-logs) database and you can access them by querying documents with a key that starts with `bulk-user-upload-`. #### Headers @@ -2770,7 +2770,7 @@ Content-Type: application/json ### POST /api/v1/users/{{username}} -Allows you to change property values on a user account. [Properties listed above]({{< ref "#supported-properties" >}}) are supported except for `contact.parent`. Creating or modifying people through the user is not supported, see the [People section]({{< ref "#people" >}}). +Allows you to change property values on a user account. [Properties listed above](/#supported-properties) are supported except for `contact.parent`. Creating or modifying people through the user is not supported, see the [People section](/#people). @@ -3128,7 +3128,7 @@ _Requires CHT Core `4.11.0` or later._ *Added in 4.3.0* -Used to retrieve a range of metrics for monitoring CHT API's performance and internals. This API is used by [CHT Watchdog]({{< ref "/technical-overview/architecture/cht-watchdog" >}}). +Used to retrieve a range of metrics for monitoring CHT API's performance and internals. This API is used by [CHT Watchdog](//technical-overview/architecture/cht-watchdog). The response is formatted for the [Prometheus Data Model](https://prometheus.io/docs/concepts/data_model/). The metrics exposed are defined by the [prometheus-api-metrics package](https://www.npmjs.com/package/prometheus-api-metrics) and include optional default metrics and garbage collection metrics. diff --git a/content/en/building/reference/app-settings/_index.md b/content/en/building/reference/app-settings/_index.md index 82f3b25162..6ff563ee50 100644 --- a/content/en/building/reference/app-settings/_index.md +++ b/content/en/building/reference/app-settings/_index.md @@ -19,7 +19,7 @@ and [`assetlinks`]({{% ref "building/reference/app-settings/assetlinks" %}}) sec `app_settings/forms.json`, `app_settings/schedules.json`, and `app_settings/assetlinks.json` respectively with the settings in the files overriding what might be already present in the `app_settings/base_settings.json` or `app_settings.json` files. -Most sections are described on their own in the [Reference Documentation]({{< ref "building/reference" >}}). +Most sections are described on their own in the [Reference Documentation](/building/reference). ## Build @@ -55,7 +55,7 @@ The following settings do not need to be specified. They should only be defined ## SMS Workflows -Workflows involving SMS are configured by defining [schedules]({{% relref "schedules" %}}), [registrations]({{% relref "registrations" %}}), [patient reports]({{% relref "patient_reports" %}}), and [case reports]({{% relref "accept_case_reports" %}}). Schedules of automated messages can be sent from the server at specified times in the future, and reports can be associated to contacts. Forms can also be configured to clear the schedule, or silence it for a period of time. +Workflows involving SMS are configured by defining [schedules](/schedules), [registrations](/registrations), [patient reports](/patient_reports), and [case reports](/accept_case_reports). Schedules of automated messages can be sent from the server at specified times in the future, and reports can be associated to contacts. Forms can also be configured to clear the schedule, or silence it for a period of time. As of `3.11.0`, places are valid subjects for any SMS workflows. ## SMS recipient resolution diff --git a/content/en/building/reference/app-settings/assetlinks.md b/content/en/building/reference/app-settings/assetlinks.md index 8e31b4f7d6..64c0ecbceb 100644 --- a/content/en/building/reference/app-settings/assetlinks.md +++ b/content/en/building/reference/app-settings/assetlinks.md @@ -14,9 +14,9 @@ aliases: *Requires CHT Core 4.7.0+, CHT Conf 3.22.0+, and CHT Android 1.3.0+* -When using a [custom flavor of cht-android]({{< ref "building/branding/android" >}}) to connect to your CHT instance, the ecosystem supports using [deep links]({{< ref "building/integrations/android#sending-a-url" >}}) to open specific content in the app. (E.g. [token login links]({{< ref "building/login#magic-links-for-logging-in-token-login" >}})). Security measures in Android require these deep links [be verified](https://developer.android.com/training/app-links/verify-android-applinks) either automatically or manually. This `assetlinks` configuration enables auto-verification for your CHT links in your Android app. The provided JSON file will be served at `https:///.well-known/assetlinks.json`. If you do not provide this configuration, users will be prompted to manually associate the CHT domain with your app. +When using a [custom flavor of cht-android](/building/branding/android) to connect to your CHT instance, the ecosystem supports using [deep links](/building/integrations/android#sending-a-url) to open specific content in the app. (E.g. [token login links](/building/login#magic-links-for-logging-in-token-login)). Security measures in Android require these deep links [be verified](https://developer.android.com/training/app-links/verify-android-applinks) either automatically or manually. This `assetlinks` configuration enables auto-verification for your CHT links in your Android app. The provided JSON file will be served at `https:///.well-known/assetlinks.json`. If you do not provide this configuration, users will be prompted to manually associate the CHT domain with your app. -For more information, see the [docs for building a new CHT Android flavor]({{< ref "building/branding/android#android-app-links-verification" >}}). +For more information, see the [docs for building a new CHT Android flavor](/building/branding/android#android-app-links-verification). Specify your digital asset links in the `app_settings/assetlinks.json` file. The `compile-app-settings` action in the `cht-conf` will automatically include this configuration in your `app_settings.json` file. Then, running the `upload-app-settings` action will deploy it to the server. @@ -27,8 +27,8 @@ Specify your digital asset links in the `app_settings/assetlinks.json` file. The | `relation[]` | `Array` | The array should contain only one element: the string `delegate_permission/common.handle_all_urls`. | yes | | `target` | `object` | Contains fields to identify associated apps. | yes | | `target.namespace` | `string` | Must be set to `android_app`. | yes | -| `target.package_name` | `string` | The [application ID]({{< ref "building/branding/android#2-new-brand" >}}) declared in the app's `build.gradle` file. | yes | -| `target.sha256_cert_fingerprints` | `Array` | The SHA256 fingerprints of your app’s signing certificate. You can get it with the Java utility `keytool`, see how exactly in our [Android guide]({{< ref "building/branding/android#hosting-assetlinksjson-with-the-cht" >}}). | yes | +| `target.package_name` | `string` | The [application ID](/building/branding/android#2-new-brand) declared in the app's `build.gradle` file. | yes | +| `target.sha256_cert_fingerprints` | `Array` | The SHA256 fingerprints of your app’s signing certificate. You can get it with the Java utility `keytool`, see how exactly in our [Android guide](/building/branding/android#hosting-assetlinksjson-with-the-cht). | yes | ## Code Sample diff --git a/content/en/building/reference/app-settings/oidc_provider.md b/content/en/building/reference/app-settings/oidc_provider.md index c0d60915b8..7c520020ff 100644 --- a/content/en/building/reference/app-settings/oidc_provider.md +++ b/content/en/building/reference/app-settings/oidc_provider.md @@ -16,7 +16,7 @@ relatedContent: > Introduced in 4.20.0. This feature is only compatible with cht-android version `v1.5.2` or greater. {{< /callout >}} -To support [authenticating users with Single Sign-On]({{< ref "/hosting/sso" >}}) (SSO) credentials (instead of CHT-specific usernames/passwords), the CHT can integrate with an external authorization server that supports the [OpenID Connect](https://openid.net/) (OIDC) protocol. Configure the OIDC Provider connection settings under the `oidc_provider` key: +To support [authenticating users with Single Sign-On](//hosting/sso) (SSO) credentials (instead of CHT-specific usernames/passwords), the CHT can integrate with an external authorization server that supports the [OpenID Connect](https://openid.net/) (OIDC) protocol. Configure the OIDC Provider connection settings under the `oidc_provider` key: ## `app_settings.json .oidc_provider` | property | type | required | description | @@ -25,9 +25,9 @@ To support [authenticating users with Single Sign-On]({{< ref "/hosting/sso" >}} | discovery_url | String | yes | The URL to the `.well-known` OIDC configuration discovery endpoint for your OIDC Provider. Must be HTTPS unless `allow_insecure_requests` is `true`. | | allow_insecure_requests | Boolean | no | Optional configuration (NOT for production use). If `true`, the `discovery_url` can use the HTTP protocol (instead of HTTPS). Default is `false`. | -When using SSO Login, the [`app_url` setting]({{< ref "building/reference/app-settings/#app_settingsjson" >}}) must also be defined. Also, your CHT application's _client secret_ from the OIDC Provider must be securely configured in your CHT instance with the [Credentials API]({{< ref "building/reference/api/#credentials" >}}) using the key `oidc:client-secret`. +When using SSO Login, the [`app_url` setting](/building/reference/app-settings/#app_settingsjson) must also be defined. Also, your CHT application's _client secret_ from the OIDC Provider must be securely configured in your CHT instance with the [Credentials API](/building/reference/api/#credentials) using the key `oidc:client-secret`. -Only users with the [`oidc_username` property]({{< ref "building/reference/api/#login-by-oidc" >}}) can log in with SSO. +Only users with the [`oidc_username` property](/building/reference/api/#login-by-oidc) can log in with SSO. ## Code sample diff --git a/content/en/building/reference/app-settings/token_login.md b/content/en/building/reference/app-settings/token_login.md index 884928214b..dbe6ef558b 100644 --- a/content/en/building/reference/app-settings/token_login.md +++ b/content/en/building/reference/app-settings/token_login.md @@ -14,7 +14,7 @@ aliases: Login via SMS settings are defined under the `token_login` key, as an object supporting the following properties: {{< callout >}} -As of CHT `5.0.0`, the [`app_url` config]({{< ref "/building/reference/app-settings/#app_settingsjson" >}}) is **required** when enabling token login. If `token_login.enabled` is `true` and `app_url` is not set, token login will not work and errors will be thrown. +As of CHT `5.0.0`, the [`app_url` config](//building/reference/app-settings/#app_settingsjson) is **required** when enabling token login. If `token_login.enabled` is `true` and `app_url` is not set, token login will not work and errors will be thrown. {{< /callout >}} ## `app_settings.json .token_login` diff --git a/content/en/building/reference/app-settings/transitions.md b/content/en/building/reference/app-settings/transitions.md index 867e067084..7a88e5b801 100644 --- a/content/en/building/reference/app-settings/transitions.md +++ b/content/en/building/reference/app-settings/transitions.md @@ -74,7 +74,7 @@ The following transitions are available and executed in order. | Key | Description | |---|---| | maintain_info_document | Records metadata about the document such as when it was replicated. Enabled by default. | -| [update_clinics](#update_clinics) | Adds a contact's info to a new data record. This is used to attribute an incoming SMS message or report to the appropriate contact. The `rc_code` value on the contact is used to match to the value of the form field set as the `facility_reference` in the [JSON form definition]({{< ref "building/reference/app-settings/forms#app_settingsjson-forms" >}}). This matching is useful when reports are sent on behalf of a facility by unknown or various phone numbers. If `facility_reference` is not set for a form, the contact match is attempted using the sender's phone number. If a form is not public and a match is not found then the `sys.facility_not_found` error is raised. A message will be sent out whenever this error is raised. | +| [update_clinics](#update_clinics) | Adds a contact's info to a new data record. This is used to attribute an incoming SMS message or report to the appropriate contact. The `rc_code` value on the contact is used to match to the value of the form field set as the `facility_reference` in the [JSON form definition](/building/reference/app-settings/forms#app_settingsjson-forms). This matching is useful when reports are sent on behalf of a facility by unknown or various phone numbers. If `facility_reference` is not set for a form, the contact match is attempted using the sender's phone number. If a form is not public and a match is not found then the `sys.facility_not_found` error is raised. A message will be sent out whenever this error is raised. | | [registration](#registration) | For registering a patient or place to a schedule. Performs some validation and creates the patient document if the patient does not already exist. Can create places (as of 3.8.x). Can assign schedules to places (as of 3.11.x) | | [accept_patient_reports](#accept-patient-reports) | Validates reports about a patient or place and silences relevant reminders. | | [accept_case_reports](#accept-case-reports) | Validates reports about a case, assigns the associated place_uuid, and silences relevant reminders. Available since 3.9.0 | @@ -400,7 +400,7 @@ Updates the target contact and all its descendants, setting the `muted` property Client-side muting runs offline on a user's device. Only the contacts and reports available on the device will be updated. - Sets the `muted` property on the target contact and all its descendants to the device's current `date` (the moment the report is processed). -- Adds/updates the [`muting_history` property]({{< ref "#client-side-muting-history" >}}) on every updated contact, to keep track of all the updates that have been processed client-side, as well as the last known server-side state of the contact and sets the `last_update` property to `client_side` +- Adds/updates the [`muting_history` property](/#client-side-muting-history) on every updated contact, to keep track of all the updates that have been processed client-side, as well as the last known server-side state of the contact and sets the `last_update` property to `client_side` - Updates the report doc to add a `client_side_transitions` property to track which transitions have run client-side #### Server-side @@ -408,8 +408,8 @@ Client-side muting runs offline on a user's device. Only the contacts and report Server-side muting runs as a typical Sentinel transition. Contacts that are already in the correct state are skipped. This applies to updates to the contact itself, updates to the Sentinel `muting_history` and to the connected registrations (registrations of a contact that is already in the correct state will not be updated). - Sets the `muted` property on the target contact and all its descendants to the moment Sentinel processed the muting action. - - If the contact was already muted by a client, the `muted` date will be overwritten. The [client-side `muting_history`]({{< ref "#client-side-muting-history" >}}) will have a copy of the client-side muting date. -- Adds a [`muting_history` entry]({{< ref "#server-side-muting-history" >}}) to Sentinel `info` docs for every updated contact + - If the contact was already muted by a client, the `muted` date will be overwritten. The [client-side `muting_history`](/#client-side-muting-history) will have a copy of the client-side muting date. +- Adds a [`muting_history` entry](/#server-side-muting-history) to Sentinel `info` docs for every updated contact - Updates all connected registrations (for the target contact and descendants), changing the state of all unsent `scheduled_tasks` to `muted` - Unsent `scheduled_tasks` have either a `scheduled` or `pending` state - Updates the contact's client-side `muting_history` to set the `last_update` property to `server_side` and update the `server_side` section with the current date and muted state. @@ -426,17 +426,17 @@ Updates the target contact's topmost muted ancestor and all its descendants, rem Client-side unmuting runs offline on a user's device. Only the contacts and reports available on the device will be updated. -- Adds/updates the [`muting_history` property]({{< ref "#client-side-muting-history" >}}) on every updated contact, sets the last known server-side state of the contact and sets the `last_update` property to `client_side` +- Adds/updates the [`muting_history` property](/#client-side-muting-history) on every updated contact, sets the last known server-side state of the contact and sets the `last_update` property to `client_side` - Updates the report doc to add a `client_side_transitions` property to track which transitions have run client-side #### Server-side Server-side unmuting runs as a typical Sentinel transition. Contacts that are already in the correct state are skipped. This applies to updates to the contact itself, updates to the Sentinel `muting_history` and to the connected registrations (registrations of a contact that is already in the correct state will not be updated). -- Adds a [`muting_history` entry]({{< ref "#server-side-muting-history" >}}) to Sentinel `info` docs for every updated contact +- Adds a [`muting_history` entry](/#server-side-muting-history) to Sentinel `info` docs for every updated contact - Updates all connected registrations (for the target contact and descendants), changing the state of all present/future `scheduled_tasks` (ones due today or in the future) with the `muted` state to have the `scheduled` state. - All `scheduled_tasks` with a due date in the past will remain unchanged. -- Updates the contact's [client-side `muting_history`]({{< ref "#client-side-muting-history" >}}) to set the `last_update` property to `server_side` and update the `server_side` section with the current date and muted state. +- Updates the contact's [client-side `muting_history`](/#client-side-muting-history) to set the `last_update` property to `server_side` and update the `server_side` section with the current date and muted state. - If the report was processed client-side, all "following" muting/unmuting events that have affected the same contacts will be replayed. This means the transition _could_ end up running multiple times over the same report. - Replaying is required due to how PouchDB <-> CouchDB synchronization does not respect the order in which the documents have been created, to ensure that contacts end up in the correct muted state. @@ -482,7 +482,7 @@ Configuration is stored in the `muting` field of `app_settings.json`. | `messages` | List of tasks/errors that will be created, determined by `event_type`. Optional. | > [!IMPORTANT] -> Contact forms cannot trigger muting or unmuting, but any `data_record` that has a `form` property (typically a [Report]({{< ref "technical-overview/data/db-schema#reports" >}})) can. +> Contact forms cannot trigger muting or unmuting, but any `data_record` that has a `form` property (typically a [Report](/technical-overview/data/db-schema#reports)) can. Supported `events_types` are: @@ -732,9 +732,9 @@ Users are automatically created for certain contacts. Both creating a new user Several configurations are required in `app_settings` to enable the `create_user_for_contacts` transition. -[Login by SMS]({{< ref "building/reference/api#login-by-sms" >}}) must be enabled by setting the `token_login` configuration. +[Login by SMS](/building/reference/api#login-by-sms) must be enabled by setting the `token_login` configuration. -The [`app_url` property]({{< ref "building/reference/app-settings#app_settingsjson" >}}) must be set to the URL of the application. This is used to generate the token login link for the new user. +The [`app_url` property](/building/reference/app-settings#app_settingsjson) must be set to the URL of the application. This is used to generate the token login link for the new user. ##### Example ```json diff --git a/content/en/building/reference/app-settings/user-permissions.md b/content/en/building/reference/app-settings/user-permissions.md index 3b37b44e6e..1ae91871a6 100644 --- a/content/en/building/reference/app-settings/user-permissions.md +++ b/content/en/building/reference/app-settings/user-permissions.md @@ -70,14 +70,14 @@ Permissions can be assigned to user roles either directly in `base_settings.json | `can_default_facility_filter` | Defaults the Place Filter in Reports tab to the user's associated facility. The user should have a contact associated that belongs to a facility. This feature is not available for Admin and Offline type of users. Use with caution, online users that can access thousands of reports can experience slow performance especially where the network is slow. Added in 4.3. | |`can_have_multiple_places`| Allows users to be assigned more than one `facility_id`. Helps support health systems where offline Supervisors manage CHWs from different geographical areas. Each `facility_id` must be at the same level in the hierarchy. Added in 4.9.0 | |`can_skip_password_change`| Turns off the password change prompt for users logging in for the first time or who have had their password reset. Added in 4.17.0 | -|`can_view_old_navigation` | Allows users to see the old CHT navigation interface, prior to the updates made to align with Material Design standards. See the [release notes]({{< ref "releases/4_12_0#navigation-updates" >}}) for more details. Added in 4.12.0. | +|`can_view_old_navigation` | Allows users to see the old CHT navigation interface, prior to the updates made to align with Material Design standards. See the [release notes](/releases/4_12_0#navigation-updates) for more details. Added in 4.12.0. | ### Legacy Permissions |Property| Description | Removed | |-------|-------------|---------| -| `can_view_old_filter_and_search` | Allows users to see the old filter and search in Reports Tab and Contact Tab which is considered deprecated. Admin user will always see the new redesigned filter. See [Feature Flags]({{< ref "/community/contributing/code/core/feature-flags" >}}) for more info. | 4.12.0 | -| `can_view_old_action_bar` | Allows users to see the old action bar in Message Tab, Reports Tab and Contact Tab which is considered deprecated. The More Options menu will be hidden when this permission is enabled. The Admin user will always see the new More Options menu. See [Feature Flags]({{< ref "/community/contributing/code/core/feature-flags" >}}) for more info. | 4.12.0 | +| `can_view_old_filter_and_search` | Allows users to see the old filter and search in Reports Tab and Contact Tab which is considered deprecated. Admin user will always see the new redesigned filter. See [Feature Flags](//community/contributing/code/core/feature-flags) for more info. | 4.12.0 | +| `can_view_old_action_bar` | Allows users to see the old action bar in Message Tab, Reports Tab and Contact Tab which is considered deprecated. The More Options menu will be hidden when this permission is enabled. The Admin user will always see the new More Options menu. See [Feature Flags](//community/contributing/code/core/feature-flags) for more info. | 4.12.0 | ### Code sample This sample shows how to define the `permissions` object in the `base_settings.json` file. Observe how `can_edit` permission has been associated to `supervisor_role` and `chw_role` user roles. diff --git a/content/en/building/reference/extension-libs.md b/content/en/building/reference/extension-libs.md index ba77770a57..96fbea0f1a 100644 --- a/content/en/building/reference/extension-libs.md +++ b/content/en/building/reference/extension-libs.md @@ -84,11 +84,11 @@ This will create or update a document to CouchDB with an ID of `extension-libs` #### CHT API -The function will now be available via the CHT API for [tasks]({{< ref "building/tasks/tasks-js" >}}), [targets]({{< ref "building/targets/targets-js" >}}), and [contact summary]({{< ref "building/contact-summary/contact-summary-templated" >}}) configurations. +The function will now be available via the CHT API for [tasks](/building/tasks/tasks-js), [targets](/building/targets/targets-js), and [contact summary](/building/contact-summary/contact-summary-templated) configurations. #### CHT xPath functions -To execute the function from within an xform use the [`cht:extension-lib` xpath function]({{< ref "building/forms/app#chtextension-lib" >}}). +To execute the function from within an xform use the [`cht:extension-lib` xpath function](/building/forms/app#chtextension-lib). ## Advanced usage diff --git a/content/en/building/reports/defining-reports.md b/content/en/building/reports/defining-reports.md index b704f10ac2..79dd018526 100644 --- a/content/en/building/reports/defining-reports.md +++ b/content/en/building/reports/defining-reports.md @@ -8,6 +8,6 @@ description: > --- The reports shown in your app are the completed and submitted *forms*. These forms must be defined and included with the application. There are two types of form definitions for reports: -- **App forms**: actions within the app, such as a completed task, or an action on a contact's profile or reports tab. App forms are defined as [XForms]({{< ref "building/forms/app" >}}). -- **JSON forms**: data coming from external channels such as SMS, or via interoperability with other tools. JSON forms are defined using a [JavaScript Object Notation schema]({{< ref "building/reference/app-settings/forms" >}}). +- **App forms**: actions within the app, such as a completed task, or an action on a contact's profile or reports tab. App forms are defined as [XForms](/building/forms/app). +- **JSON forms**: data coming from external channels such as SMS, or via interoperability with other tools. JSON forms are defined using a [JavaScript Object Notation schema](/building/reference/app-settings/forms). diff --git a/content/en/building/reports/reports-overview.md b/content/en/building/reports/reports-overview.md index 63152d370b..d638d70e5d 100644 --- a/content/en/building/reports/reports-overview.md +++ b/content/en/building/reports/reports-overview.md @@ -9,7 +9,7 @@ description: > The Reports tab is where you can access submitted data. Depending on how often you anticipate a user needing to access this tab, you can configure it to show in the main tabs list (preferable for admin users) or in the secondary hamburger menu (preferable for CHW users). -The permissions set for your role and your placement in the hierarchy will determine which reports you’re able to see on this tab. As a rule, you can only view reports submitted by yourself or those below you in the [hierarchy]({{< ref "building/workflows/hierarchy" >}}). Therefore, CHWs will only see reports that they submitted on this tab, while supervisors will see reports that they submitted as well as those submitted by their CHWs. Advanced configuration options are available for a specific off-line user role to manage what [level of report data]({{< ref "technical-overview/data/performance/replication#report-depth" >}}) is copied to their device. +The permissions set for your role and your placement in the hierarchy will determine which reports you’re able to see on this tab. As a rule, you can only view reports submitted by yourself or those below you in the [hierarchy](/building/workflows/hierarchy). Therefore, CHWs will only see reports that they submitted on this tab, while supervisors will see reports that they submitted as well as those submitted by their CHWs. Advanced configuration options are available for a specific off-line user role to manage what [level of report data](/technical-overview/data/performance/replication#report-depth) is copied to their device. {{< figure src="reports-desktop.png" link="reports-desktop.png" class="left col-9 col-lg-9" >}} @@ -46,14 +46,14 @@ Using the search box, you can search for reports by patient name, phone number, > [!NOTE] -> A new user experience for Filter and Search was introduced in v3.17. The previous version can be re-enabled for users by adding the [permission]({{< ref "building/reference/app-settings/user-permissions" >}}) `can_view_old_filter_and_search` to the user's role; however, the old version should be considered deprecated and will be completely removed in a future release. See [Feature Flags]({{< ref "/community/contributing/code/core/feature-flags" >}}) documentation for more info +> A new user experience for Filter and Search was introduced in v3.17. The previous version can be re-enabled for users by adding the [permission](/building/reference/app-settings/user-permissions) `can_view_old_filter_and_search` to the user's role; however, the old version should be considered deprecated and will be completely removed in a future release. See [Feature Flags](//community/contributing/code/core/feature-flags) documentation for more info ## Action Buttons -The action buttons at the bottom of the screen are configurable using [permissions]({{< ref "building/reference/app-settings/user-permissions" >}}). Options include submit, edit, delete, review and export reports. +The action buttons at the bottom of the screen are configurable using [permissions](/building/reference/app-settings/user-permissions). Options include submit, edit, delete, review and export reports. Clicking on the “Export” button will download a CSV file with all the data from the reports. And clicking the “+ Submit report” button opens a menu of forms a user can choose to complete. @@ -63,7 +63,7 @@ Clicking on the “Export” button will download a CSV file with all the data f ## Bulk Delete Reports -Allows the user to select multiple reports and delete them. **Please Note**: This action cannot be undone. If in doubt, do not delete! You can restrict a user’s access to this feature by disabling the [permission]({{< ref "building/reference/app-settings/user-permissions" >}}) `can_bulk_delete_reports`. +Allows the user to select multiple reports and delete them. **Please Note**: This action cannot be undone. If in doubt, do not delete! You can restrict a user’s access to this feature by disabling the [permission](/building/reference/app-settings/user-permissions) `can_bulk_delete_reports`. {{< cards >}} {{< card link="reports-bulk-mobile.png" image="reports-bulk-mobile.png" method="resize">}} diff --git a/content/en/building/targets/target-widgets.md b/content/en/building/targets/target-widgets.md index 5d34633a27..2be033bdfb 100644 --- a/content/en/building/targets/target-widgets.md +++ b/content/en/building/targets/target-widgets.md @@ -21,21 +21,21 @@ You will be adding target widgets that will allow Community Health Workers (CHWs ## Brief Overview of Key Concepts -*[Targets]({{< ref "building/targets/targets-overview" >}})* is the user dashboard or analytics tab. +*[Targets](/building/targets/targets-overview)* is the user dashboard or analytics tab. -*[Target widgets]({{< ref "building/targets/targets-overview#types-of-widgets" >}})* provide a summary or analysis of the data in submitted reports. +*[Target widgets](/building/targets/targets-overview#types-of-widgets)* provide a summary or analysis of the data in submitted reports. -*[Count widgets]({{< ref "building/targets/targets-overview#count-widgets" >}})* show a tally of a particular report that has been submitted or data within a report that matches a set of criteria. +*[Count widgets](/building/targets/targets-overview#count-widgets)* show a tally of a particular report that has been submitted or data within a report that matches a set of criteria. -*[Percent widgets]({{< ref "building/targets/targets-overview#percent-widgets" >}})* display a ratio, which helps to provide insight into the proportion that matches a defined criteria. +*[Percent widgets](/building/targets/targets-overview#percent-widgets)* display a ratio, which helps to provide insight into the proportion that matches a defined criteria. -*[Target schema]({{< ref "building/targets/targets-js#targetsjs" >}})* details a set of properties for targets. +*[Target schema](/building/targets/targets-js#targetsjs)* details a set of properties for targets. *Target instance* is an object emitted and counted or aggregated based on target configuration. ## Required Resources -You should have a functioning [CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}), completed a [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) setup, and an [assessment form]({{< ref "building/tutorials/app-forms" >}}). +You should have a functioning [CHT instance with `cht-conf` installed locally](/building/local-setup), completed a [project folder](/building/local-setup#3-create-and-upload-a-blank-project) setup, and an [assessment form](/building/tutorials/app-forms). ## Implementation Steps @@ -378,7 +378,7 @@ targets.assessments.percentage.cough.title = % Population with cough targets.households.with.assessments.title = Total households with assessments targets.households.with.gt2.assessments.title = % Household with >=2 assessments ``` -To upload *[translations]({{< ref "building/translations/localizing" >}})* to your local instance, run the following command: +To upload *[translations](/building/translations/localizing)* to your local instance, run the following command: ```zsh cht --url=https://:@localhost --accept-self-signed-certs upload-custom-translations @@ -392,7 +392,7 @@ The image shows the updated target titles. Your image may be different depending > Be sure to have the correct translation key in your target widget's `translation_key` property. ### 10. Target icons -You may add `icons` to your target widgets to enhance their appearance and to help users locate specific widgets more quickly. Use the icons in the *[targets icon library]({{< ref "design/interface/icons/forms_tasks_targets" >}})*, or icons of your choice for the target widgets. Add your selected icons to the `resources` folder in your project folder. In your `resources.json` *file*, add key/value pairs for your icon resources. +You may add `icons` to your target widgets to enhance their appearance and to help users locate specific widgets more quickly. Use the icons in the *[targets icon library](/design/interface/icons/forms_tasks_targets)*, or icons of your choice for the target widgets. Add your selected icons to the `resources` folder in your project folder. In your `resources.json` *file*, add key/value pairs for your icon resources. ```json { @@ -406,7 +406,7 @@ You may add `icons` to your target widgets to enhance their appearance and to he {{< see-also page="design/interface/icons" title="Icon Library" >}} -To upload *[resources]({{< ref "building/branding/resources#icons" >}})* to your local instance, run the following command: +To upload *[resources](/building/branding/resources#icons)* to your local instance, run the following command: ```zsh cht --url=https://:@localhost --accept-self-signed-certs upload-resources diff --git a/content/en/building/targets/targets-js.md b/content/en/building/targets/targets-js.md index 3a6e7395f2..c3c8f9abf4 100644 --- a/content/en/building/targets/targets-js.md +++ b/content/en/building/targets/targets-js.md @@ -48,7 +48,7 @@ All targets are defined in the `targets.js` file as an array of objects accordin | `groupBy` | `function(contact, report)` returning string | Allows for target ids to be aggregated and scored in groups. Not required for most targets. Use with passesIfGroupCount. | no | | `passesIfGroupCount` | `object` | The criteria to determine if the target ids within a group should be counted as passing | yes when `groupBy` is defined | | `passesIfGroupCount.gte` | `number` | The group should be counted as passing if the number of target ids in the group is greater-than-or-equal-to this value | yes when `groupBy` is defined | -| `dhis` | `object` or `object[]` | Settings relevant to the [DHIS2 Integration]({{< ref "building/integrations/dhis2-aggregate#configuration" >}}) | no +| `dhis` | `object` or `object[]` | Settings relevant to the [DHIS2 Integration](/building/integrations/dhis2-aggregate#configuration) | no | `dhis[n].dataElement` | `string` | The hash id of a data element configured in the DHIS2 data set you're integrating with | yes | `dhis[n].dataSet` | `string` | The hash id of the data set that contains the data element you're integrating with. If this is left undefined, the data element will appear in all data sets. | no | `visible` | `boolean` | Whether the target is visible in the targets page. **Default: true** | no | diff --git a/content/en/building/tasks/complex-tasks.md b/content/en/building/tasks/complex-tasks.md index 1ee80a8a29..131c690b91 100644 --- a/content/en/building/tasks/complex-tasks.md +++ b/content/en/building/tasks/complex-tasks.md @@ -23,12 +23,12 @@ Tasks prompt users to complete activities on a programmatic schedule. This tutor ## Prerequisites -* [Building a simple task]({{< ref "building/tasks/simple-tasks" >}}) -* [Maternal and Newborn Health Reference App]({{< ref "reference-apps/maternal-newborn" >}}) +* [Building a simple task](/building/tasks/simple-tasks) +* [Maternal and Newborn Health Reference App](/reference-apps/maternal-newborn) ## Scenario -This scenario is loosely based on the _Pregnancy Visit Task_ from the [Maternal and Newborn Health Reference App]({{< ref "reference-apps/maternal-newborn" >}}). +This scenario is loosely based on the _Pregnancy Visit Task_ from the [Maternal and Newborn Health Reference App](/reference-apps/maternal-newborn). We expectations for the task are: @@ -103,9 +103,9 @@ module.exports = { 2. Pregnancy visits should appear for pregnant patients after their pregnancy registration ``` -This function starts with the standard stuff from the [Configuring Tasks Tutorial]({{< ref "building/tasks/simple-tasks" >}}). We want to confirm the user is a CHW, and the patient is alive and unmuted. +This function starts with the standard stuff from the [Configuring Tasks Tutorial](/building/tasks/simple-tasks). We want to confirm the user is a CHW, and the patient is alive and unmuted. -Then, the code searches through each contact's reports to find the most recent (_newest_) pregnancy registration using the [Utils helper library]({{< ref "building/reference/_partial_utils" >}}). It gets that report's value for `report.fields.g_details.estimated_lmp`, which is a date string calculated by the app form. It parses that string using the luxon library and returns true if it is a valid date. +Then, the code searches through each contact's reports to find the most recent (_newest_) pregnancy registration using the [Utils helper library](/building/reference/_partial_utils). It gets that report's value for `report.fields.g_details.estimated_lmp`, which is a date string calculated by the app form. It parses that string using the luxon library and returns true if it is a valid date. Defining `lmp` as a property of `this`, _stores_ the LMP DateTime and we will use that value later. @@ -114,7 +114,7 @@ Defining `lmp` as a property of `this`, _stores_ the LMP DateTime and we will us 3. Pregnancy visits should be scheduled eight times between the last mentrual period (LMP) and delivery. ``` -This is a recurring task, unlike the one-time task we wrote in [Configuring Tasks Tutorial]({{< ref "building/tasks/simple-tasks" >}}). This task is going to appear once 12 weeks after the estimated LMP date, again after 20 weeks, and again 6 more times. The `dueDate` on the event says that the task event is due _a variable number of weeks after the estimated LMP_. The time the CHW has to complete the visit is shorter toward the end of the schedule. +This is a recurring task, unlike the one-time task we wrote in [Configuring Tasks Tutorial](/building/tasks/simple-tasks). This task is going to appear once 12 weeks after the estimated LMP date, again after 20 weeks, and again 6 more times. The `dueDate` on the event says that the task event is due _a variable number of weeks after the estimated LMP_. The time the CHW has to complete the visit is shorter toward the end of the schedule. We're using the `this.lmp` value which was calculated and saved in the `appliesIf` function. @@ -123,15 +123,15 @@ We're using the `this.lmp` value which was calculated and saved in the `appliesI 4. A pregnancy visit should be skipped if an _assessment followup_ is completed within the scheduled window for the pregancy visit. ``` -`resolvedIf` captures the conditions when the task event should disappear because it has been _completed_. Since we want the task schedule to appear if the user completes an _assessment followup_ or the _pnc followup_, we can't use the [default resolvedIf definition]({{< ref "building/tasks/tasks-js#default-resolvedif-method" >}}). +`resolvedIf` captures the conditions when the task event should disappear because it has been _completed_. Since we want the task schedule to appear if the user completes an _assessment followup_ or the _pnc followup_, we can't use the [default resolvedIf definition](/building/tasks/tasks-js#default-resolvedif-method). -This function calculates timestamps for the start and end of each event. Then, it uses the [Utils helper library]({{< ref "building/reference/_partial_utils" >}}) to see if _either_ a _pnc_ or an _assessment_ followup is present within those timestamps. +This function calculates timestamps for the start and end of each event. Then, it uses the [Utils helper library](/building/reference/_partial_utils) to see if _either_ a _pnc_ or an _assessment_ followup is present within those timestamps. -The concept of _task completion_ is covered in more depth in [Task Completion vs Cancellation]({{< ref "building/tasks/managing-tasks/query-task-data#completion-vs-cancellation" >}}). +The concept of _task completion_ is covered in more depth in [Task Completion vs Cancellation](/building/tasks/managing-tasks/query-task-data#completion-vs-cancellation). ## Actions ``` 5. The first pregnancy visit should prompt the CHW to ask some additional questions ``` -The `modifyContent` attribute allows the task to pass data from the task (in JavaScript) into the action app form (xlsx). Check out the guide for [Passing data from a task into the app form]({{< ref "building/tasks/managing-tasks/pass-data-to-form" >}}). +The `modifyContent` attribute allows the task to pass data from the task (in JavaScript) into the action app form (xlsx). Check out the guide for [Passing data from a task into the app form](/building/tasks/managing-tasks/pass-data-to-form). diff --git a/content/en/building/tasks/managing-tasks/launch-contact-form.md b/content/en/building/tasks/managing-tasks/launch-contact-form.md index 70efafac14..ff93f6b81c 100644 --- a/content/en/building/tasks/managing-tasks/launch-contact-form.md +++ b/content/en/building/tasks/managing-tasks/launch-contact-form.md @@ -17,7 +17,7 @@ Note that submitting the contact form does not automatically resolve the task. ## Create contact -To configure a task action to redirect the user to a create contact form, use the [`modifyContent` function]({{< ref "building/tasks/tasks-js/#tasksjs" >}}) to set the `type` and `parent_id` values for the new contact in the action `content`. When the user selects the action, they will automatically be redirected to the create contact form (located at `contacts/{{parent_id}}/add/{{type}}`). +To configure a task action to redirect the user to a create contact form, use the [`modifyContent` function](/building/tasks/tasks-js/#tasksjs) to set the `type` and `parent_id` values for the new contact in the action `content`. When the user selects the action, they will automatically be redirected to the create contact form (located at `contacts/{{parent_id}}/add/{{type}}`). The following example task config will create a task for all new households (`clinic` contacts), prompting the user to add new members to the household. When the user selects the task, they will be presented with two actions. The "Add person to household" action will redirect the user to the create contact form for a new `person` contact, with the `parent_id` set to the household contact. This action can be performed as many times as needed to add multiple members to the household. The second action, "No more household members to add", will open an `app` form to confirm all members have been added to the household. Submitting that form will resolve the task. @@ -59,7 +59,7 @@ A task action can also be configured to redirect the user to the create contact Added in CHT `4.21.0`. {{< /callout >}} -To configure a task action to redirect the user to an edit contact form, use the [`modifyContent` function]({{< ref "building/tasks/tasks-js/#tasksjs" >}}) to set the `edit_id` field in the action `content` to the identifier of the contact to edit. When the user selects the action, they will automatically be redirected to the edit contact form for the identified contact (located at `contacts/{{edit_id}}/edit`). +To configure a task action to redirect the user to an edit contact form, use the [`modifyContent` function](/building/tasks/tasks-js/#tasksjs) to set the `edit_id` field in the action `content` to the identifier of the contact to edit. When the user selects the action, they will automatically be redirected to the edit contact form for the identified contact (located at `contacts/{{edit_id}}/edit`). The following example task config will create a task for new person contacts that do not have a `role` value. When the user selects the task, they will be redirected to the edit contact form for the person (where they can set the `role` value). Populating the `role` value for the person will cause the task to be cancelled and no longer displayed. diff --git a/content/en/building/tasks/managing-tasks/pass-data-to-form.md b/content/en/building/tasks/managing-tasks/pass-data-to-form.md index 9134669322..4dd932018b 100644 --- a/content/en/building/tasks/managing-tasks/pass-data-to-form.md +++ b/content/en/building/tasks/managing-tasks/pass-data-to-form.md @@ -16,15 +16,15 @@ This guide explains how to pass data from a task into the action _application fo ## Prerequisites -* [Complex Tasks Tutorial]({{< ref "building/tasks/complex-tasks" >}}) -* [Application Forms Tutorial]({{< ref "building/tutorials/app-forms" >}}) +* [Complex Tasks Tutorial](/building/tasks/complex-tasks) +* [Application Forms Tutorial](/building/tutorials/app-forms) ## Scenario -Let's look deeper at the scenario from the [Complex Tasks Tutorial]({{< ref "building/tasks/complex-tasks" >}}) where we have an ANC follow-up task which recurs eight times, and we want to ask the user different questions on the first and last follow-up. +Let's look deeper at the scenario from the [Complex Tasks Tutorial](/building/tasks/complex-tasks) where we have an ANC follow-up task which recurs eight times, and we want to ask the user different questions on the first and last follow-up. ## Developing the task -From the [Complex Tasks Tutorial]({{< ref "building/tasks/complex-tasks" >}}), here is the task. +From the [Complex Tasks Tutorial](/building/tasks/complex-tasks), here is the task. ```javascript const { DateTime } = require('luxon'); @@ -75,7 +75,7 @@ module.exports = { ``` ## modifyContent -Let's take a look at the `actions` section and specifically the [modifyContent]({{< ref "building/tasks/tasks-js" >}}) attribute. This `modifyContent` attribute allows the task to pass data from the task (in JavaScript) into the action app form (xlsx). The `content` object is the object which binds to the `inputs` section in the app form. You can pass data into the app form by assigning values onto this object. +Let's take a look at the `actions` section and specifically the [modifyContent](/building/tasks/tasks-js) attribute. This `modifyContent` attribute allows the task to pass data from the task (in JavaScript) into the action app form (xlsx). The `content` object is the object which binds to the `inputs` section in the app form. You can pass data into the app form by assigning values onto this object. This function calculates `t_followup_count` to be the index of the event which is being completed. So the first task event (which appears after 12 weeks) is followup `1`, and the task event after 34 weeks is followup `5`. diff --git a/content/en/building/tasks/managing-tasks/query-task-data.md b/content/en/building/tasks/managing-tasks/query-task-data.md index 61f5f275ed..76b09aece9 100644 --- a/content/en/building/tasks/managing-tasks/query-task-data.md +++ b/content/en/building/tasks/managing-tasks/query-task-data.md @@ -19,15 +19,15 @@ This guide explains the data which results from tasks and how to query it. ## Prerequisites -* [Data Flows for Analytics]({{< ref "technical-overview/data/analytics/data-flows-for-analytics" >}}) +* [Data Flows for Analytics](/technical-overview/data/analytics/data-flows-for-analytics) ## Querying task data -The task system running on each user's device is powered by [task documents]({{< ref "technical-overview/data/db-schema#tasks" >}}) and those task documents sync to the server and to PostgreSQL just like a contact or a report. Having task documents in PostgreSQL allows system administrators to analyse how users are interacting with tasks. +The task system running on each user's device is powered by [task documents](/technical-overview/data/db-schema#tasks) and those task documents sync to the server and to PostgreSQL just like a contact or a report. Having task documents in PostgreSQL allows system administrators to analyse how users are interacting with tasks. {{< see-also page="technical-overview/data/analytics/data-flows-for-analytics" title="Data flows for analytics" >}} ### First Assessment Completion Rate -Working with the _First Assessment_ task from the [Configuring Tasks Tutorial]({{< ref "building/tasks/simple-tasks" >}}), let's try to answer the question **What percentage of the scheduled _first assessment_ events have been completed?**. +Working with the _First Assessment_ task from the [Configuring Tasks Tutorial](/building/tasks/simple-tasks), let's try to answer the question **What percentage of the scheduled _first assessment_ events have been completed?**. Let's query data from the last three months to see how the _first assessment_ task is behaving in production: @@ -66,9 +66,9 @@ module.exports = [{ ``` **What is this code doing?** -* `useview_task` - This is a materialized view of the data from the [task document schema]({{< ref "technical-overview/data/db-schema#tasks" >}}). -* `task_state` - The meaning of each task state is explained in the [task document schema]({{< ref "technical-overview/data/db-schema#tasks" >}}). -* `WHERE title` - The _name_ attribute in the [task.js schema]({{< ref "building/tasks/tasks-js#tasksjs" >}}) is used exclusively in the task's backend data. Here we limit the query to task documents resulting from our named task. The `title` in postgres maps to the `name` in JavaScript not the `title` in JavaScript - which is confusing. +* `useview_task` - This is a materialized view of the data from the [task document schema](/technical-overview/data/db-schema#tasks). +* `task_state` - The meaning of each task state is explained in the [task document schema](/technical-overview/data/db-schema#tasks). +* `WHERE title` - The _name_ attribute in the [task.js schema](/building/tasks/tasks-js#tasksjs) is used exclusively in the task's backend data. Here we limit the query to task documents resulting from our named task. The `title` in postgres maps to the `name` in JavaScript not the `title` in JavaScript - which is confusing. * `WHERE duedate` - One task document is created per event and this task has one event per contact which is due 7 days after the contact's creation date. Here we limit the query to task documents which are _due in the last 3 calendar months_. ## Understanding the data diff --git a/content/en/building/tasks/managing-tasks/task-schema-parameters.md b/content/en/building/tasks/managing-tasks/task-schema-parameters.md index 354c7d0ad9..58e0174de5 100644 --- a/content/en/building/tasks/managing-tasks/task-schema-parameters.md +++ b/content/en/building/tasks/managing-tasks/task-schema-parameters.md @@ -22,13 +22,13 @@ This guide explains the parameters available in the Task Schema and important co Let's synthesize some knowledge about CHT applications to help clarify what is happening within the task system: -1. All contacts in CHT applications are organised into hierarchies. For more information, read the [Contact and User Management Tutorial]({{< ref "building/contact-management/contact-and-users-1" >}}) or [schema for contact documents]({{< ref "technical-overview/data/db-schema#contacts-persons-and-places" >}}). +1. All contacts in CHT applications are organised into hierarchies. For more information, read the [Contact and User Management Tutorial](/building/contact-management/contact-and-users-1) or [schema for contact documents](/technical-overview/data/db-schema#contacts-persons-and-places). -2. All reports in the system are linked to one (and only one) contact. For more information, read [App Forms Tutorial]({{< ref "building/tutorials/app-forms" >}}) or the [schema for report documents]({{< ref "technical-overview/data/db-schema#reports" >}}). +2. All reports in the system are linked to one (and only one) contact. For more information, read [App Forms Tutorial](/building/tutorials/app-forms) or the [schema for report documents](/technical-overview/data/db-schema#reports). -3. Documents are stored [minified]({{< ref "technical-overview/data/hydration" >}}) (not hydrated). All data that is passed into the tasks system is minified. +3. Documents are stored [minified](/technical-overview/data/hydration) (not hydrated). All data that is passed into the tasks system is minified. -4. Settings which control the documents which are available on the user's device are an important considerations to remember (eg [replication depth]({{< ref "technical-overview/data/performance/replication#depth" >}}) or [purging]({{< ref "technical-overview/data/performance/purging" >}})) since both tasks can only process docs which are present on the device. +4. Settings which control the documents which are available on the user's device are an important considerations to remember (eg [replication depth](/technical-overview/data/performance/replication#depth) or [purging](/technical-overview/data/performance/purging)) since both tasks can only process docs which are present on the device. > [!IMPORTANT] > The code in `tasks.js` runs on the user's devices, not in the cloud and not on a server. @@ -44,7 +44,7 @@ With this constraint in mind, we can infer that tasks cannot know the answer to ## The special significance of the appliesTo attribute -The [task.js schema]({{< ref "building/tasks/tasks-js#tasksjs" >}}) includes the noteworthy attribute `appliesTo` which has two options: `contacts` and `reports`. This attribute is important! It changes the algorithm used to process the task, and the meaning of other attributes in the schema. +The [task.js schema](/building/tasks/tasks-js#tasksjs) includes the noteworthy attribute `appliesTo` which has two options: `contacts` and `reports`. This attribute is important! It changes the algorithm used to process the task, and the meaning of other attributes in the schema. > [!TIP] > `appliesTo` is important. When you're ready to write a task, one of the first thing you must decide is the `appliesTo` value. diff --git a/content/en/building/tasks/simple-priority-score.md b/content/en/building/tasks/simple-priority-score.md index b316b22bf7..a5107e7812 100644 --- a/content/en/building/tasks/simple-priority-score.md +++ b/content/en/building/tasks/simple-priority-score.md @@ -27,8 +27,8 @@ You will define: ## Prerequisites -- You have already defined the relevant task types in `task.js`. If not, review the [Tasks tutorial]({{< ref "building/tasks/simple-tasks" >}}) to learn how to structure tasks. -- Read [Understanding the data available in tasks and targets]({{< ref "building/tasks/managing-tasks/task-schema-parameters" >}}) +- You have already defined the relevant task types in `task.js`. If not, review the [Tasks tutorial](/building/tasks/simple-tasks) to learn how to structure tasks. +- Read [Understanding the data available in tasks and targets](/building/tasks/managing-tasks/task-schema-parameters) ## Implementation Steps diff --git a/content/en/building/tasks/simple-tasks.md b/content/en/building/tasks/simple-tasks.md index 099e3fccae..102dde9347 100644 --- a/content/en/building/tasks/simple-tasks.md +++ b/content/en/building/tasks/simple-tasks.md @@ -15,16 +15,16 @@ aliases: - /apps/tutorials/tasks-1 --- -Tasks prompt users to complete activities on a programmatic schedule. This guide will explain how to write a task which prompts CHW users to complete an _assessment_ [app form]({{< ref "building/tutorials/app-forms" >}}) for new patients within 7 days of registration. +Tasks prompt users to complete activities on a programmatic schedule. This guide will explain how to write a task which prompts CHW users to complete an _assessment_ [app form](/building/tutorials/app-forms) for new patients within 7 days of registration. - Creating a straight-forward task - Running and testing that task ## Prerequisites -* Complete the [App Forms Tutorial]({{< ref "building/tutorials/app-forms" >}}) - Tasks prompt users to _complete activities_ by opening an app form. The app forms tutorial produces an _assessment_ app form which we will use here. You can also elect to substitute that with any [example app form](https://github.com/medic/cht-core/tree/master/config/default/forms/app). -* Complete the [Contact and User Management - Part 1 Tutorial]({{< ref "building/contact-management/contact-and-users-2" >}}) to create a hierarchy of contacts and an offline CHW user. -* Read [Understanding the data available in tasks and targets]({{< ref "building/tasks/managing-tasks/task-schema-parameters" >}}) +* Complete the [App Forms Tutorial](/building/tutorials/app-forms) - Tasks prompt users to _complete activities_ by opening an app form. The app forms tutorial produces an _assessment_ app form which we will use here. You can also elect to substitute that with any [example app form](https://github.com/medic/cht-core/tree/master/config/default/forms/app). +* Complete the [Contact and User Management - Part 1 Tutorial](/building/contact-management/contact-and-users-2) to create a hierarchy of contacts and an offline CHW user. +* Read [Understanding the data available in tasks and targets](/building/tasks/managing-tasks/task-schema-parameters) ## Implementation Steps @@ -53,14 +53,14 @@ module.exports = [{ **What is this code doing?** -The `tasks.js` file follows the JavaScript ES6 Module syntax and _exports_ an array of objects matching the [task.js schema]({{< ref "building/tasks/tasks-js#tasksjs" >}})*. In the code above, the `tasks.js` file is exporting one task object with the following: +The `tasks.js` file follows the JavaScript ES6 Module syntax and _exports_ an array of objects matching the [task.js schema](/building/tasks/tasks-js#tasksjs)*. In the code above, the `tasks.js` file is exporting one task object with the following: * `name` - This is used exclusively in the task's backend data. The _name_ isn't controlling any element of the tasks's behaviour, appearance, or schedule. -* `title` - This is controlling the "Task title" as defined in the [anatomy of a task]({{< ref "design/best-practices#anatomy-of-a-task" >}}). -* `icon` - This references a [resource]({{< ref "building/branding/resources" >}}) to be used as the task's icon. Refer to [anatomy of a task]({{< ref "design/best-practices#anatomy-of-a-task" >}}). -* `appliesTo` - We use `contacts` because we want one task _per contact_. For more details, read [Understanding the data available in tasks and targets]({{< ref "building/tasks/managing-tasks/task-schema-parameters" >}}). +* `title` - This is controlling the "Task title" as defined in the [anatomy of a task](/design/best-practices#anatomy-of-a-task). +* `icon` - This references a [resource](/building/branding/resources) to be used as the task's icon. Refer to [anatomy of a task](/design/best-practices#anatomy-of-a-task). +* `appliesTo` - We use `contacts` because we want one task _per contact_. For more details, read [Understanding the data available in tasks and targets](/building/tasks/managing-tasks/task-schema-parameters). * `appliesToType` - The task should only show for contacts with `contact_type` equal to `patient`. This `appliesToType` is a _short-hand_ equivalent to `appliesIf: c => c.contact.contact_type === 'patient'`. -* `appliesIf` - A predicate which gates the creation of the task's event schedule. For more details, read [Understanding the data available in tasks and targets]({{< ref "building/tasks/managing-tasks/task-schema-parameters" >}}). +* `appliesIf` - A predicate which gates the creation of the task's event schedule. For more details, read [Understanding the data available in tasks and targets](/building/tasks/managing-tasks/task-schema-parameters). * `user.parent.contact_type` - The user is a CHW iff their parent is of type `chw_area`. The user object is hydrated. * `!c.contact.date_of_death` - The contact must be alive * `!c.contact.muted` - The contact must be unmuted @@ -86,7 +86,7 @@ cht --url=https://:@localhost compile-app-settings upload-ap ### 3. Testing the Task -Tasks are only available to [offline users]({{< ref "building/users#offline-users" >}}). To view and test this simple task, you'll need to login as an offline user like the CHW-level user created in the [Contact and User Management - Part 1 Tutorial]({{< ref "building/contact-management/contact-and-users-1" >}}). Once logged in, sync to make sure you have the latest configuration. You may be prompted to reload the application. +Tasks are only available to [offline users](/building/users#offline-users). To view and test this simple task, you'll need to login as an offline user like the CHW-level user created in the [Contact and User Management - Part 1 Tutorial](/building/contact-management/contact-and-users-1). Once logged in, sync to make sure you have the latest configuration. You may be prompted to reload the application. Create a new contact in the hierarchy and navigate to the `Tasks` tab. You should see the new `assessment-after-registration` task! @@ -100,7 +100,7 @@ Next, test a few of the expected behaviours for the task: * Move your system clock forward 8 days and reload the tasks tab. The task should disappear since the 7 day window has expired. * Login as a supervisor user. You should not be able to see the task. * The task should not appear only for patients - not for places or CHWs. -* If you mute a contact or [report the contact dead]({{< ref "building/workflows/death-reporting" >}}), the task should disappear. +* If you mute a contact or [report the contact dead](/building/workflows/death-reporting), the task should disappear. > [!IMPORTANT] > Remember to reset your system clock to be accurate when you are done testing. diff --git a/content/en/building/tasks/tasks-js.md b/content/en/building/tasks/tasks-js.md index 8aa67bc8c8..8776922dc9 100644 --- a/content/en/building/tasks/tasks-js.md +++ b/content/en/building/tasks/tasks-js.md @@ -29,9 +29,9 @@ Task generation occurs on the client periodically and creates documents which tr | `name`| `string` | A unique identifier for the task. Used for querying task completeness. | yes, unique | | `icon` | `string` | The icon to show alongside the task. Should correspond with a value defined in `resources.json`. | no | | `title` | `translation key` | The title of the task (labeled above). | yes | -| `appliesTo` | `'contacts'` or `'reports'` | Do you want to emit one task per report, or one task per contact? See [Understanding the Parameters in the Task Schema]({{< ref "building/tasks/managing-tasks/task-schema-parameters.md" >}}). | yes | -| `appliesIf` | `function(contact, report)` | If `appliesTo: 'contacts'`, this function is invoked once per contact and `report` is undefined. If `appliesTo: 'reports'`, this function is invoked once per report. Return true if the task should appear for the given documents. See [Understanding the Parameters in the Task Schema]({{< ref "building/tasks/managing-tasks/task-schema-parameters.md" >}}). | no | -| `appliesToType` | `string[]` | Filters the contacts or reports for which `appliesIf` will be evaluated. If `appliesTo: 'reports'`, this is an array of form codes. For example, `['pregnancy']` or `['P', 'pregnancy']`. If `appliesTo: 'contacts'`, this is an array of contact types. For example, `['person']` or `['clinic', 'health_center']`. See [Understanding the Parameters in the Task Schema]({{< ref "building/tasks/managing-tasks/task-schema-parameters.md" >}}). | no | +| `appliesTo` | `'contacts'` or `'reports'` | Do you want to emit one task per report, or one task per contact? See [Understanding the Parameters in the Task Schema](/building/tasks/managing-tasks/task-schema-parameters.md). | yes | +| `appliesIf` | `function(contact, report)` | If `appliesTo: 'contacts'`, this function is invoked once per contact and `report` is undefined. If `appliesTo: 'reports'`, this function is invoked once per report. Return true if the task should appear for the given documents. See [Understanding the Parameters in the Task Schema](/building/tasks/managing-tasks/task-schema-parameters.md). | no | +| `appliesToType` | `string[]` | Filters the contacts or reports for which `appliesIf` will be evaluated. If `appliesTo: 'reports'`, this is an array of form codes. For example, `['pregnancy']` or `['P', 'pregnancy']`. If `appliesTo: 'contacts'`, this is an array of contact types. For example, `['person']` or `['clinic', 'health_center']`. See [Understanding the Parameters in the Task Schema](/building/tasks/managing-tasks/task-schema-parameters.md). | no | | `contactLabel` | `string` or `function(contact, report)` | Controls the label describing the subject of the task. Defaults to the name of the contact (`contact.contact.name`). | no | | `resolvedIf` | `function(contact, report, event, dueDate)` | Return true to mark the task as "resolved". A resolved task uses memory on the phone, but is not displayed. | no, if any `actions[n].type` is `'report'` | | `events` | `object[]` | An event is used to specify the timing of the task. | yes | @@ -41,10 +41,10 @@ Task generation occurs on the client periodically and creates documents which tr | `events[n].start` | `integer` | Number of days to show the task before it is due. | yes | | `events[n].end` | `integer` | Number of days to show the task after it is due. | yes | | `actions` | `object[]` | The actions (forms) that a user can access after clicking on a task. If you put multiple forms here, the user will see a task summary screen where they can select which action they would like to complete. | yes | -| `actions[n].type` | `'report'` or `'contact'` | When `'report'`, the action opens the given form. When `'contact'`, the action redirects to a contact's profile page or opens a `contact` form. See [Launching a contact form from a task]({{< ref "building/tasks/managing-tasks/launch-contact-form" >}}). Defaults to 'report'. | no | +| `actions[n].type` | `'report'` or `'contact'` | When `'report'`, the action opens the given form. When `'contact'`, the action redirects to a contact's profile page or opens a `contact` form. See [Launching a contact form from a task](/building/tasks/managing-tasks/launch-contact-form). Defaults to 'report'. | no | | `actions[n].form` | `string` | The code of the form that should open when you select the action. | yes, if `actions[n].type` is `'report'` | | `actions[n].label`| `translation key` | The label that should appear on the task summary screen if multiple actions are present. | no | -| `actions[n].modifyContent`| `function (content, contact, report, event)` | Set the values on the content object to control the data which will be passed as `inputs` to the form which opens when the action is selected. See [Passing data from a task into the app form]({{< ref "building/tasks/managing-tasks/pass-data-to-form" >}}). | no | +| `actions[n].modifyContent`| `function (content, contact, report, event)` | Set the values on the content object to control the data which will be passed as `inputs` to the form which opens when the action is selected. See [Passing data from a task into the app form](/building/tasks/managing-tasks/pass-data-to-form). | no | | `priority` | `object` or `function(contact, report)` returning object of same schema | Controls the "high risk" line seen above. | no | | `priority.level` | `integer` | A positive number representing a task’s urgency. Tasks with a higher level will appear at the top of the list. | no | | `priority.label` | `translation key` | Text shown with the task associated to the risk level. | no | diff --git a/content/en/building/training/users-bulk-load.md b/content/en/building/training/users-bulk-load.md index 771ae05570..43a13aa153 100644 --- a/content/en/building/training/users-bulk-load.md +++ b/content/en/building/training/users-bulk-load.md @@ -115,7 +115,7 @@ In this example the "Penda Ouedraogo" place has gotten an updated UUID starting 5. Export spreadsheet into CSV {{< figure src="importing-users-export-csv.png" link="importing-users-export-csv.png" caption="export spreadsheet into CSV" >}} -6. Access the [Admin Console]({{< ref "building/admin/" >}}) of your instance, go to "Users", click "Import from file" and select your CSV file you just exported +6. Access the [Admin Console](/building/admin/) of your instance, go to "Users", click "Import from file" and select your CSV file you just exported {{< figure src="importing-users-import-csv.png" link="importing-users-import-csv.png" caption="import CSV into CHT" >}} 7. Be patient during import (testing showed ~0.4 seconds per record up to 500 records) @@ -157,7 +157,7 @@ Add some new rows at the bottom (item 1), enter the new place name in column A ( The third use case mentioned in the [workbook instructions section](#workbook-instructions) links to a Google Sheets to create user places alongside their account and their contact. This works out of the box with the `default` CHT configuration but will require adjustments to be made in the `place.type_VLOOKUP` spreadsheet when dealing with a CHT configuration with custom places types. -The `place.type_VLOOKUP` spreadsheet has two columns that contain the name of the places types set in the [`.contact_types[]`]({{< relref "building/reference/app-settings/hierarchy" >}}) property of your `app_settings.json` and their respective IDs. The place type name is used by the `User-Place-Type:excluded` column in the `contact.chw` spreadsheet to provide a user-friendly way to pick a place with autocompletion. You will want to keep this spreadsheet in sync with your CHT configuration to create users' places. +The `place.type_VLOOKUP` spreadsheet has two columns that contain the name of the places types set in the [`.contact_types[]`](/building/reference/app-settings/hierarchy) property of your `app_settings.json` and their respective IDs. The place type name is used by the `User-Place-Type:excluded` column in the `contact.chw` spreadsheet to provide a user-friendly way to pick a place with autocompletion. You will want to keep this spreadsheet in sync with your CHT configuration to create users' places. ## Trouble shooting diff --git a/content/en/building/translations/localizing.md b/content/en/building/translations/localizing.md index 862f58e22e..a30899a14c 100644 --- a/content/en/building/translations/localizing.md +++ b/content/en/building/translations/localizing.md @@ -14,7 +14,7 @@ aliases: This section will take you through translating the CHT to a custom language (in this guide, Swahili). This will include setting up the user interface labels as well as outgoing text messages. > [!TIP] -> If you need to translate the whole app into an entirely new language, please consider [contributing those translations]({{< ref "community/contributing/translations" >}}) to the core project so they are available to the community. +> If you need to translate the whole app into an entirely new language, please consider [contributing those translations](/community/contributing/translations) to the core project so they are available to the community. By the end of the section you should be able to: @@ -23,8 +23,8 @@ By the end of the section you should be able to: ## Prerequisites -- A local CHT instance [with `cht-conf` installed locally]({{< ref "building/local-setup" >}}) -- A [project folder]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) +- A local CHT instance [with `cht-conf` installed locally](/building/local-setup) +- A [project folder](/building/local-setup#3-create-and-upload-a-blank-project) - CHT Swahili translations in a `messages-sw.properties` file. ## Localization Steps diff --git a/content/en/building/translations/overview.md b/content/en/building/translations/overview.md index 8b7c59157e..6fe2e3452e 100644 --- a/content/en/building/translations/overview.md +++ b/content/en/building/translations/overview.md @@ -10,28 +10,28 @@ aliases: - /apps/reference/translations --- -Given that CHT applications are used around the world, the Core Framework was designed with localization in mind. The Core Framework is available in English, French, Nepali, Swahili, Spanish, [and more]({{< ref "community/contributing/translations" >}})! +Given that CHT applications are used around the world, the Core Framework was designed with localization in mind. The Core Framework is available in English, French, Nepali, Swahili, Spanish, [and more](/community/contributing/translations)! ## Key Concepts *Localization* refers to setting up the desired language in CHT for the end user. See an outline of how to change language settings for CHT users [in the dedicated section](#localization). -*Translations* refers to manually setting up extra translations of instance tabs texts or outgoing SMS text. See an outline of how to add new translations to the CHT [in the dedicated section]({{< ref "building/translations/localizing" >}}). +*Translations* refers to manually setting up extra translations of instance tabs texts or outgoing SMS text. See an outline of how to add new translations to the CHT [in the dedicated section](/building/translations/localizing). ## Localization In the `app_settings.json` file the default language for the application is set by the `locale` property, along with a separate default language for outgoing messages that are sent via SMS with the `locale_outgoing` property. -Additionally, languages available to the user can be enabled and disabled through [the `languages` property]({{< ref "building/reference/app-settings#app_settingsjson" >}}) which contains an array of objects. These objects should contain the `locale` and `enabled` properties representing respectively the 2 or 3 letter language code and whether that language should be enabled. +Additionally, languages available to the user can be enabled and disabled through [the `languages` property](/building/reference/app-settings#app_settingsjson) which contains an array of objects. These objects should contain the `locale` and `enabled` properties representing respectively the 2 or 3 letter language code and whether that language should be enabled. ### Forms Translations for XForms are defined within the forms themselves. The XLSForm notation is [documented here](http://xlsform.org/en/#multiple-language-support), and would use the corresponding 2-character language codes. ### Reports -Submitted forms are shown on the Reports tab, with each value in the report displayed alongside a label. The label for each value is represented by a key in the `report.{form-name}.{field-name}` format, which can be translated by including the key and translation in the [language files]( {{< relref "#translations" >}} ). If the label is omitted in the translation the full key will show in the app. +Submitted forms are shown on the Reports tab, with each value in the report displayed alongside a label. The label for each value is represented by a key in the `report.{form-name}.{field-name}` format, which can be translated by including the key and translation in the [language files](/#translations). If the label is omitted in the translation the full key will show in the app. > [!NOTE] -> To hide report fields from showing on the Reports view altogether, the containing group or field must be included as `hidden_fields`, as per the [form properties file]( {{< ref "building/forms/app#properties" >}} ). +> To hide report fields from showing on the Reports view altogether, the containing group or field must be included as `hidden_fields`, as per the [form properties file]( {{< ref "building/forms/app#properties" >}}). ### Build diff --git a/content/en/building/tutorials/app-forms.md b/content/en/building/tutorials/app-forms.md index 59373b2cf6..35b5d5bb16 100644 --- a/content/en/building/tutorials/app-forms.md +++ b/content/en/building/tutorials/app-forms.md @@ -27,15 +27,15 @@ You will be building assessment workflow that allows Community Health Workers to ## Brief Overview of Key Concepts -*[App forms]({{< ref "building/forms/app" >}})* serve as actions within the app. +*[App forms](/building/forms/app)* serve as actions within the app. -*[XLSForm]({{< ref "building/forms/app#xlsform" >}})* is a form [standard](http://xlsform.org/en/) created to help simplify the authoring of forms in Excel. +*[XLSForm](/building/forms/app#xlsform)* is a form [standard](http://xlsform.org/en/) created to help simplify the authoring of forms in Excel. -*[XForm]({{< ref "building/forms/app#xform" >}})* is a CHT-enhanced version of the [ODK XForm](https://getodk.github.io/xforms-spec/) standard. +*[XForm](/building/forms/app#xform)* is a CHT-enhanced version of the [ODK XForm](https://getodk.github.io/xforms-spec/) standard. ## Required Resources -You should have a [functioning CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}) and a [project folder set up]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}) already. +You should have a [functioning CHT instance with `cht-conf` installed locally](/building/local-setup) and a [project folder set up](/building/local-setup#3-create-and-upload-a-blank-project) already. ## Implementation Steps @@ -128,4 +128,4 @@ cht --url=https://:@localhost --accept-self-signed-certs con ## Next steps -- *[Setting Form Properties]({{< ref "building/forms/form-properties/" >}})* +- *[Setting Form Properties](/building/forms/form-properties/)* diff --git a/content/en/building/tutorials/application-tests.md b/content/en/building/tutorials/application-tests.md index 577981acf6..825e64922b 100644 --- a/content/en/building/tutorials/application-tests.md +++ b/content/en/building/tutorials/application-tests.md @@ -19,10 +19,10 @@ This tutorial takes you through testing the various configurable components of C ## Prerequisites Complete the following tutorials: - - [Building App Forms]({{< ref "building/tutorials/app-forms" >}}) - - [Building A Simple Task]({{< ref "building/tasks/simple-tasks" >}}) - - [Building Target Widgets]({{< ref "building/targets/target-widgets" >}}) - - [Building Contact Summary]({{< ref "building/contact-summary/contact-summary-overview" >}}) + - [Building App Forms](/building/tutorials/app-forms) + - [Building A Simple Task](/building/tasks/simple-tasks) + - [Building Target Widgets](/building/targets/target-widgets) + - [Building Contact Summary](/building/contact-summary/contact-summary-overview) ## Importance of testing your application --- @@ -39,7 +39,7 @@ Using `cht-conf-test-harness`, you can write tests and run them with [Mocha](htt ## Preparation Writing tests for CHT apps requires a good understanding of the project workflows and requirements. To test using the harness, there are a few things you need to set up: -1. From the previous tutorials, you should have a [functioning CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}) and a [project folder set up]({{< ref "building/local-setup#3-create-and-upload-a-blank-project" >}}). +1. From the previous tutorials, you should have a [functioning CHT instance with `cht-conf` installed locally](/building/local-setup) and a [project folder set up](/building/local-setup#3-create-and-upload-a-blank-project). `cht-conf` which is short for CHT app configurer, is a command-line interface tool used to manage and configure your CHT apps. It is used for backup, conversion, validation, uploading and other actions which can be found by running `cht --help`. 2. Ensure your `package.json` file has the required libraries. A `package.json` file is used to record important metadata about a project and defines functional attributes that npm uses to install dependencies and run scripts. This file should be at the root of your project folder. If your `package.json` file does not already have them, add `cht-conf-test-harness`, `chai`, and `mocha` by running this in your command-line: @@ -133,7 +133,7 @@ After each test run, assert that there are no errors in the console. If you want to learn more about these hooks, refer to this [Mocha resource](https://mochajs.org/#hooks). Feel free to customize the hooks as you see fit. -Let's look at a more detailed example. Here is a test case for the Assessment form that was covered in the [previous tutorial]({{< ref "building/tutorials/app-forms" >}}): +Let's look at a more detailed example. Here is a test case for the Assessment form that was covered in the [previous tutorial](/building/tutorials/app-forms): ```js highlight it('unit test confirming assessment with cough since 7 days', async () => { @@ -235,7 +235,7 @@ Contact summary consists of visible components such as [cards](https://docs.comm Use [harness.getContactSummary()](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/Harness.html#getContactSummary) method to get the [ContactSummary ](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/global.html#ContactSummary)object, which has these properties: `fields`, `cards`, and `context`. -To test the contact summary fields added in the [previous tutorial]({{< ref "building/contact-summary/contact-summary-overview#3-export-fields" >}}), use the following test case: +To test the contact summary fields added in the [previous tutorial](/building/contact-summary/contact-summary-overview#3-export-fields), use the following test case: ```js highlight const contactSummary = await harness.getContactSummary(); @@ -252,7 +252,7 @@ expect(contactSummary.fields.filter(f => f.filter !== 'lineage')).to.deep.equal( Here, the contact summary being tested represents the contact that is being "acted on" or the "subject of the test". To learn more about this, look at the `subject` property [here](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/global.html#HarnessInputs). -Similarly, you can test the condition cards too. Here is an example for testing the assessment condition card added in this [tutorial]({{< ref "building/condition-cards#2-define-cards-and-add-a-condition-card-object" >}}): +Similarly, you can test the condition cards too. Here is an example for testing the assessment condition card added in this [tutorial](/building/condition-cards#2-define-cards-and-add-a-condition-card-object): ```js highlight // Load the assessment form and fill in 'yes' on the first page and '7' on the second page @@ -279,7 +279,7 @@ expect(contactSummary.cards[0].fields).to.deep.equal( ] ); ``` -If you follow [this code sample]({{< ref "building/contact-summary/contact-summary-templated#code-samples" >}}) to create the pregnancy condition card, the pregnancy context can be tested this way: +If you follow [this code sample](/building/contact-summary/contact-summary-templated#code-samples) to create the pregnancy condition card, the pregnancy context can be tested this way: ```js highlight const summaryContext = harness.getContactSummary().context; @@ -296,7 +296,7 @@ expect(summaryContext).to.include({ |Minimum:|Trigger and resolve the task| |Ideal:|One test for each use scenario
Code coverage for any arc with an external dependency
Negative cases - confirm tasks don’t trigger| -When testing the tasks [manually]({{< ref "building/tasks/simple-tasks#3-testing-the-task" >}}), you need to fill a form. Then to see the task, you need to either change the system date to move forward in time or change the reported date of the document accordingly. These are very tedious and unreliable methods. Using the test harness, you can quickly test the tasks under different scenarios and at different simulated dates. +When testing the tasks [manually](/building/tasks/simple-tasks#3-testing-the-task), you need to fill a form. Then to see the task, you need to either change the system date to move forward in time or change the reported date of the document accordingly. These are very tedious and unreliable methods. Using the test harness, you can quickly test the tasks under different scenarios and at different simulated dates. Every task has a source document (contact or report). When testing, you can mock the source document. Yet, the recommended approach is to fill the source form and then proceed with checking the associated tasks. @@ -312,7 +312,7 @@ Commonly used harness methods when testing tasks are: With `getTasks()`, you get an array of [`Task`](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/global.html#Task) objects which corresponds to the [tasks schema](https://docs.communityhealthtoolkit.org/technical-overview/data/db-schema/#tasks). -Let's look back at the simple task from this tutorial: [Building A Simple Task]({{< ref "building/tasks/simple-tasks" >}}). +Let's look back at the simple task from this tutorial: [Building A Simple Task](/building/tasks/simple-tasks). According to the task configuration, these conditions need to be met for the assessment task to be visible: 1. The `contact_type` of the subject (patient) is: `patient` @@ -448,7 +448,7 @@ Testing a target is relatively straightforward. Add a report or contact that inc Use [`harness.getTargets`](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/Harness.html#getTargets) to check the state of targets. It returns a [`Target`](https://docs.communityhealthtoolkit.org/cht-conf-test-harness/global.html#Target) object which corresponds to the [targets schema](https://docs.communityhealthtoolkit.org/technical-overview/data/db-schema/#targets). -To test the first two targets created in the [targets tutorial]({{< ref "building/targets/target-widgets" >}}), use this code: +To test the first two targets created in the [targets tutorial](/building/targets/target-widgets), use this code: ```js highlight it('assessment this month and all time assessments should show correct counts', async () => { //set the current date diff --git a/content/en/building/tutorials/sms-forms.md b/content/en/building/tutorials/sms-forms.md index 70276ddb1e..20ffa00666 100644 --- a/content/en/building/tutorials/sms-forms.md +++ b/content/en/building/tutorials/sms-forms.md @@ -27,11 +27,11 @@ You will be building a pregnancy registration workflow that allows Community Hea ## Brief Overview of Key Concepts -*[SMS forms]({{< ref "building/reference/app-settings/forms" >}})* are structured text messages that contain a form code representing a report type and some information associated with the report. +*[SMS forms](/building/reference/app-settings/forms)* are structured text messages that contain a form code representing a report type and some information associated with the report. -SMS forms are defined in either the `base_settings.json` or the `app_settings/forms.json` file and compiled into the *[app_settings.json]({{< ref "building/reference/app-settings" >}})* file with the `compile-app-settings` action in the `cht-conf` tool, then stored in the settings doc in the database. +SMS forms are defined in either the `base_settings.json` or the `app_settings/forms.json` file and compiled into the *[app_settings.json](/building/reference/app-settings)* file with the `compile-app-settings` action in the `cht-conf` tool, then stored in the settings doc in the database. -*[SMS gateways]({{< ref "building/messaging/gateways" >}})* allow the CHT core framework to send and receive SMS transmission to or from a mobile network operator. +*[SMS gateways](/building/messaging/gateways)* allow the CHT core framework to send and receive SMS transmission to or from a mobile network operator. *SMS aggregators* act as intermediaries between the mobile network operators and the CHT core framework. They allow for greater customization of SMS workflows in the CHT. @@ -39,13 +39,13 @@ SMS forms are defined in either the `base_settings.json` or the `app_settings/fo ## Required Resources -You should have a [functioning CHT instance with `cht-conf` installed locally]({{< ref "building/local-setup" >}}). +You should have a [functioning CHT instance with `cht-conf` installed locally](/building/local-setup). You also need to have some [prior knowledge on `app_settings.json`]({{% ref "building/tutorials/application-settings" %}}). ## Implementation Steps -SMS forms are defined [using JSON]({{< ref "building/reference/app-settings/forms#app_settingsjson-forms" >}}) in the `app_settings.json` file. +SMS forms are defined [using JSON](/building/reference/app-settings/forms#app_settingsjson-forms) in the `app_settings.json` file. ### 1. Enable Transitions @@ -145,10 +145,10 @@ To set the validation rules and autoresponses, edit the array corresponding to t ] ``` -You can also define your own [validation rules]({{< ref "building/reference/app-settings#validations" >}}). +You can also define your own [validation rules](/building/reference/app-settings#validations). > [!NOTE] -> `translation_key` represents the message that is sent out. This will be defined in a [translations]({{< ref "building/translations/localizing" >}}) file. +> `translation_key` represents the message that is sent out. This will be defined in a [translations](/building/translations/localizing) file. ### 3. Define a Person Registration Form diff --git a/content/en/building/tutorials/sms-schedules.md b/content/en/building/tutorials/sms-schedules.md index ed8e53253d..794a9327fd 100644 --- a/content/en/building/tutorials/sms-schedules.md +++ b/content/en/building/tutorials/sms-schedules.md @@ -20,17 +20,17 @@ This tutorial takes you through how to set up SMS schedules for CHT applications ## Brief Overview of Key Concepts -*[SMS schedules]({{< ref "building/reference/app-settings/schedules" >}})* are a series of SMS messages that are to be sent to specific contacts at future dates and times. They are defined in either the `base_settings.json` or the `app_settings/schedules.json` file and compiled into the *[app_settings.json]({{< ref "building/reference/app-settings" >}})* file with the `compile-app-settings` action in the `cht-conf` tool. +*[SMS schedules](/building/reference/app-settings/schedules)* are a series of SMS messages that are to be sent to specific contacts at future dates and times. They are defined in either the `base_settings.json` or the `app_settings/schedules.json` file and compiled into the *[app_settings.json](/building/reference/app-settings)* file with the `compile-app-settings` action in the `cht-conf` tool. -SMS schedules can be triggered by *[SMS forms]({{< ref "building/tutorials/sms-forms" >}})* or *[App forms]({{< ref "building/forms/app" >}})*. +SMS schedules can be triggered by *[SMS forms](/building/tutorials/sms-forms)* or *[App forms](/building/forms/app)*. ## Required Resources -You should have [built a pregnancy SMS form]({{< ref "building/tutorials/sms-forms#4-define-a-report-submission-form" >}}). +You should have [built a pregnancy SMS form](/building/tutorials/sms-forms#4-define-a-report-submission-form). ## Implementation Steps -SMS schedules are defined [using JSON]({{< ref "building/reference/app-settings/schedules#app_settingsjson-schedules" >}}) in the `app_settings.json` file. +SMS schedules are defined [using JSON](/building/reference/app-settings/schedules#app_settingsjson-schedules) in the `app_settings.json` file. ### 1. Define a Pregnancy Follow Up Schedule diff --git a/content/en/building/users.md b/content/en/building/users.md index f6ad21eb11..74f95199fd 100644 --- a/content/en/building/users.md +++ b/content/en/building/users.md @@ -38,7 +38,7 @@ Online roles are for users who need access to a lot of data and need to maintain Offline roles are for users who need to be able to access data on-the-go in the field and don’t have a reliable internet connection. All the data they have access to will be synced to their device. System administrators cannot be offline users as they won't have access to the app management tools offline. > [!NOTE] -> Advanced configuration options are available for a specific offline user role to manage what [level of data]({{< ref "technical-overview/data/performance/replication" >}}) is synced to their device. +> Advanced configuration options are available for a specific offline user role to manage what [level of data](/technical-overview/data/performance/replication) is synced to their device. ## Permissions diff --git a/content/en/building/workflows/workflows-overview.md b/content/en/building/workflows/workflows-overview.md index 44b117cda8..77713ab6e2 100644 --- a/content/en/building/workflows/workflows-overview.md +++ b/content/en/building/workflows/workflows-overview.md @@ -14,7 +14,7 @@ Workflows can be defined within apps built with the Core Framework to connect ac Tasks within the app can drive a workflow, ensuring that the right actions are taken for people at the right time. Tasks indicate a recommended action to the user. They indicate who the user should perform the action with, and the recommended timeframe of that action. When the user taps the task, they are directed to a form where the details of the action are captured. -Tasks can be triggered by a set of conditions, such as contact details or submitted reports. Tasks are accessible in the Tasks tab and the profile in the Contact tab, and initiate a follow up action to complete a form. More information on building app workflows is available in the [Tasks section]({{< ref "building/tasks" >}}). +Tasks can be triggered by a set of conditions, such as contact details or submitted reports. Tasks are accessible in the Tasks tab and the profile in the Contact tab, and initiate a follow up action to complete a form. More information on building app workflows is available in the [Tasks section](/building/tasks). Data submitted in one form can generate several tasks at once, for example, multiple ANC visits following one pregnancy registration. Some workflows involve a series of sequential forms and tasks, such as a child health assessment form, a follow up task scheduled 48 hours later, a referral form (only if the child’s condition hasn’t improved), and then a referral follow up task. Tasks are accessible on the Tasks tab, as well as the Tasks section of profiles. diff --git a/content/en/community/contributing/code/android/development-setup.md b/content/en/community/contributing/code/android/development-setup.md index 769ff4f663..2d58705554 100644 --- a/content/en/community/contributing/code/android/development-setup.md +++ b/content/en/community/contributing/code/android/development-setup.md @@ -114,7 +114,7 @@ Each APK will be generated and stored in `build/outputs/apk/[flavor]/[debug|rele To assemble other flavors, use the following command: `make flavour=[Flavor] assemble`. See the [Flavor selection](#flavor-selection) section for more details about `make` commands. -To create the `.aab` bundle file, use `make bundle`, although signed versions are generated when [releasing]({{< ref "community/contributing/code/android/releasing" >}}), and the Play Store requires the AAB to be signed with the right key. +To create the `.aab` bundle file, use `make bundle`, although signed versions are generated when [releasing](/community/contributing/code/android/releasing), and the Play Store requires the AAB to be signed with the right key. To clean the APKs and compiled resources: `make clean`. diff --git a/content/en/community/contributing/code/android/releasing.md b/content/en/community/contributing/code/android/releasing.md index 60a4fe0072..f6e4c643b4 100644 --- a/content/en/community/contributing/code/android/releasing.md +++ b/content/en/community/contributing/code/android/releasing.md @@ -32,5 +32,5 @@ All Medic's Android projects automatically build, sign, and release builds via G 1. Update the CHANGELOG with the details of what's in this release. 1. Repeat steps 2-3 from the above [alpha release section](#alpha-for-release-testing) with the naming convention `v..`. 1. The CI build for the tag will create a new draft release on GitHub. Include the release notes from the CHANGELOG in the description of the release and publish the release on GitHub. -1. [Publish]({{< ref "building/branding/publishing" >}}) in the Play Store. For the CHT-Android app, the "reference" apps (`medicmobilegamma` and `unbranded`) must be published in the Play Store. Other channels such as F-Droid can also be used to publish the app. +1. [Publish](/building/branding/publishing) in the Play Store. For the CHT-Android app, the "reference" apps (`medicmobilegamma` and `unbranded`) must be published in the Play Store. Other channels such as F-Droid can also be used to publish the app. 1. Announce the release on the [CHT forum](https://forum.communityhealthtoolkit.org), under the "Product - Releases" category. diff --git a/content/en/community/contributing/code/core/apdex-automation-tests.md b/content/en/community/contributing/code/core/apdex-automation-tests.md index a6683e495c..0023a99b1b 100644 --- a/content/en/community/contributing/code/core/apdex-automation-tests.md +++ b/content/en/community/contributing/code/core/apdex-automation-tests.md @@ -15,7 +15,7 @@ This documentation will guide you on how to setup and configure automation to ru ## Prerequisites Before continuing with the steps below, ensure: -1. You have a [cht instance deployed]({{< ref "/hosting/cht/app-developer" >}}) and running either locally or globally. +1. You have a [cht instance deployed](//hosting/cht/app-developer) and running either locally or globally. 1. You have some pre-existing users and data already loaded on the app. Use the [test-data-generator](https://github.com/medic/test-data-generator) tool to achieve this. diff --git a/content/en/community/contributing/code/core/automated-tests.md b/content/en/community/contributing/code/core/automated-tests.md index d3e8b95be9..7fbea52063 100644 --- a/content/en/community/contributing/code/core/automated-tests.md +++ b/content/en/community/contributing/code/core/automated-tests.md @@ -449,8 +449,8 @@ Any test code that starts a server or runs an executable is running outside of t The CHT Community is here to help you succeed with testing: - Questions? Ask in the [Community Forum](https://forum.communityhealthtoolkit.org/) -- Need help debugging? Check the [Troubleshooting Guide]({{< ref "community/contributing/code/core/automated-tests#debugging-e2e-tests" >}}) +- Need help debugging? Check the [Troubleshooting Guide](/community/contributing/code/core/automated-tests#debugging-e2e-tests) - Found a bug? [Open an issue](https://github.com/medic/cht-core/issues) -- Want to contribute to testing? See the [Contribution Guide]({{< ref "community/contributing/code/core/automated-tests#ways-to-get-involved" >}}) +- Want to contribute to testing? See the [Contribution Guide](/community/contributing/code/core/automated-tests#ways-to-get-involved) Remember, every contributor was once new to the project. Don't hesitate to ask for help! diff --git a/content/en/community/contributing/code/core/feature-flags.md b/content/en/community/contributing/code/core/feature-flags.md index 6f10bf7b00..8d24a86020 100644 --- a/content/en/community/contributing/code/core/feature-flags.md +++ b/content/en/community/contributing/code/core/feature-flags.md @@ -20,7 +20,7 @@ Some CHT Core features can be enabled for specific users only. This can be parti ## Configuration -If the specific CHT Core feature supports feature flagging, users can be configured to see the "old" version by means of a [permission]({{< ref "building/reference/app-settings/user-permissions" >}}). The permission can be added to existing Roles, or for more granular control and rolling out by cohorts, you can create a new Role with the one permission and add that Role to desired users. The permission will not be included in `app_settings` automatically so if you want it to be selectable from the Admin app user interface, you will need to add it to `app_settings`. +If the specific CHT Core feature supports feature flagging, users can be configured to see the "old" version by means of a [permission](/building/reference/app-settings/user-permissions). The permission can be added to existing Roles, or for more granular control and rolling out by cohorts, you can create a new Role with the one permission and add that Role to desired users. The permission will not be included in `app_settings` automatically so if you want it to be selectable from the Admin app user interface, you will need to add it to `app_settings`. ## Roll-out Scenarios diff --git a/content/en/community/contributing/code/releasing/_index.md b/content/en/community/contributing/code/releasing/_index.md index c22c0bee9b..f12db645ab 100644 --- a/content/en/community/contributing/code/releasing/_index.md +++ b/content/en/community/contributing/code/releasing/_index.md @@ -64,4 +64,4 @@ Follow the [instructions in the readme](https://github.com/medic/cht-conf/#user- ## Android apps -Follow the instructions in the [Android > Releasing]({{< ref "community/contributing/code/android/releasing" >}}) section. +Follow the instructions in the [Android > Releasing](/community/contributing/code/android/releasing) section. diff --git a/content/en/community/contributing/code/repository-checklist.md b/content/en/community/contributing/code/repository-checklist.md index 922081f031..e538e3b4a8 100644 --- a/content/en/community/contributing/code/repository-checklist.md +++ b/content/en/community/contributing/code/repository-checklist.md @@ -18,7 +18,7 @@ When creating a new CHT Product repository under [Medic's GitHub organization](h - [ ] Issue templates exist. - [ ] PR template exists. - [ ] PRs reference related issues. -- [ ] Commit formats follow the [guidelines]({{< ref "workflow/#commits" >}}). +- [ ] Commit formats follow the [guidelines](/workflow/#commits). - [ ] Secrets are not part of the commit history or made public. - [ ] The following files exist: - `LICENSE` specifying AGPL-3.0 ([example](https://github.com/medic/cht-core/blob/master/LICENSE)) diff --git a/content/en/community/contributing/code/static-analysis.md b/content/en/community/contributing/code/static-analysis.md index 6f756e5248..1f09dedc0a 100644 --- a/content/en/community/contributing/code/static-analysis.md +++ b/content/en/community/contributing/code/static-analysis.md @@ -43,16 +43,16 @@ When Sonar flags an issue with the code in your pull request, use this decision 1. Fix it and push the updated code to your PR. The PR will automatically be unblocked once the Sonar analysis succeeds. 1. If the issue is a "false-positive" (i.e. Sonar has flagged some particular code as violating a rule, but it does not make sense to apply the rule in that context): 1. If the rule is one that should not be applied to any CHT code: - 1. [Remove the rule]({{< ref "#removing-a-rule" >}}) from the default Quality Profile. + 1. [Remove the rule](/#removing-a-rule) from the default Quality Profile. 1. If it does not make sense to apply the rule to this particular code, you can do one of the following: 1. Completely ignore Sonar issues [on that line of code](https://docs.sonarsource.com/sonarqube-server/latest/user-guide/issues/managing/) by adding the `// NOSONAR` comment to the end of the line. - 1. Completely ignore Sonar issues for [that block of code]({{< ref "#ignoring-all-rules-for-a-block-of-code" >}}). - 1. Update the `.sonarcloud.properties` to [ignore _that rule_ for that particular file]({{< ref "#ignoring-a-specific-rule-for-a-file" >}}). - 1. Update the `.sonarcloud.properties` to [ignore _all rules_ for that particular file]({{< ref "#ignoring-all-rules-for-a-file" >}}) (useful if the file has been copied from an external dependency). + 1. Completely ignore Sonar issues for [that block of code](/#ignoring-all-rules-for-a-block-of-code). + 1. Update the `.sonarcloud.properties` to [ignore _that rule_ for that particular file](/#ignoring-a-specific-rule-for-a-file). + 1. Update the `.sonarcloud.properties` to [ignore _all rules_ for that particular file](/#ignoring-all-rules-for-a-file) (useful if the file has been copied from an external dependency). ### Adding a new repo to SonarCloud -1. Add a `.sonarcloud.properties` file to the repository with your desired [repo-level configuration]({{< ref "#ignoring-all-rules-for-a-file" >}}). +1. Add a `.sonarcloud.properties` file to the repository with your desired [repo-level configuration](/#ignoring-all-rules-for-a-file). 2. In the GitHub UI, navigate to the settings for the [`medic` org > Third-party Access > GitHub Apps](https://github.com/organizations/medic/settings/installations) 3. Find SonarCloud and click the `Configure` button. 4. In the Repository access section, select your desired repository from the drop-down and click `Save`. diff --git a/content/en/community/contributing/code/style-guide.md b/content/en/community/contributing/code/style-guide.md index bac5d7a626..3fd0287543 100644 --- a/content/en/community/contributing/code/style-guide.md +++ b/content/en/community/contributing/code/style-guide.md @@ -259,7 +259,7 @@ const getResult = () => ### Implicit Returns -As [noted above]({{< ref "#use-arrow-functions" >}}), implicit returns should be used for one-line arrow functions. However, for the sake of readability, they should not be used when returning a multi-line value. +As [noted above](/#use-arrow-functions), implicit returns should be used for one-line arrow functions. However, for the sake of readability, they should not be used when returning a multi-line value. *Right:* diff --git a/content/en/community/contributing/code/troubleshooting/obtaining-logs.md b/content/en/community/contributing/code/troubleshooting/obtaining-logs.md index cde6cb128d..efe0c8749b 100644 --- a/content/en/community/contributing/code/troubleshooting/obtaining-logs.md +++ b/content/en/community/contributing/code/troubleshooting/obtaining-logs.md @@ -52,7 +52,7 @@ The Android log is written to from the cht-android wrapper which captures errors ### Step 1 -To install the `adb` command, follow the instructions under the [Development Environment > Debug tool adb]({{< ref "community/contributing/code/android/development-setup#debug-tool-adb" >}}) section. +To install the `adb` command, follow the instructions under the [Development Environment > Debug tool adb](/community/contributing/code/android/development-setup#debug-tool-adb) section. ### Step 2 diff --git a/content/en/community/contributing/code/workflow.md b/content/en/community/contributing/code/workflow.md index 71aa451791..ce981e9138 100644 --- a/content/en/community/contributing/code/workflow.md +++ b/content/en/community/contributing/code/workflow.md @@ -10,15 +10,15 @@ aliases: ## Writing code -Where possible, follow the [coding style guide]({{< ref "community/contributing/code/style-guide" >}}). +Where possible, follow the [coding style guide](/community/contributing/code/style-guide). Aim for self-documenting code. Where code cannot be made self-documenting add commenting. Usually comments are useful when they explain why some code exists, and should not be explaining what some code is doing. ### Code Quality -Several [static analysis tools]({{< ref "community/contributing/code/static-analysis" >}}) are used to support code quality. These tools are run automatically on every pull request and will fail the build if they find any issues. +Several [static analysis tools](/community/contributing/code/static-analysis) are used to support code quality. These tools are run automatically on every pull request and will fail the build if they find any issues. -For a more efficient feedback loop, developers should run linting scripts locally before pushing code to the repository. Additionally, both [ESLint]({{< ref "community/contributing/code/static-analysis#eslint" >}}) and [Sonar]({{< ref "community/contributing/code/static-analysis#during-development" >}}) have IDE plugins that show code issues in real-time. +For a more efficient feedback loop, developers should run linting scripts locally before pushing code to the repository. Additionally, both [ESLint](/community/contributing/code/static-analysis#eslint) and [Sonar](/community/contributing/code/static-analysis#during-development) have IDE plugins that show code issues in real-time. ## Issues @@ -52,7 +52,7 @@ Issues in this column are complete, all code has been merged into the main branc The main branch is `main` (or `master`) which must be kept stable so as not to impact other developers and so a release branch can be created as needed. To achieve this, development should be done in a branch (only possible for maintaners) or fork and submitted via a PR for code review. This means the CI runs and another developer has signed off on the change before it is included in the `main` branch. -Create a branch following the guideline below and push [commits]({{< ref "#commits" >}}) at least once a day to a remote repository. This ensures that the code is always backed up and safe, protects against accidental deletes, and allows community members to see the latest changes and work together more effectively. +Create a branch following the guideline below and push [commits](/#commits) at least once a day to a remote repository. This ensures that the code is always backed up and safe, protects against accidental deletes, and allows community members to see the latest changes and work together more effectively. - The main branch is `main` or `master` and is the GitHub default branch and contains the latest code. - Release branches have the form `..x` and should be stable. @@ -107,7 +107,7 @@ Once your pull request has been approved, it can be merged to the main branch by When merging a PR, avoid the "Create a merge commit" option. Merge commits in the main branch cause the history of the branch to be non-linear and make it more difficult to understand exactly when a code change was introduced. Instead, use the "Squash and merge" option to combine the commits in the PR into a single commit on the main branch. Alternatively, you can use the "Rebase and merge" option if you want _all_ the commits in the PR to be preserved in the main branch (this should only be used in special cases). -See above for instructions on [how to format your commit messages]({{< ref "#commit-message-format" >}}). +See above for instructions on [how to format your commit messages](/#commit-message-format). #### Opening Pull Requests @@ -116,7 +116,7 @@ Create a Draft Pull Request to facilitate discussion and collaboration with qual Once you are confident that the change is complete and ready to be merged: 1. Change the Pull Request from `Draft` to `Ready for review`. -2. The Pull Request title will be the commit message, it is important to follow the [commit message format]({{< ref "#commit-message-format" >}}) to name the Pull Request title properly. +2. The Pull Request title will be the commit message, it is important to follow the [commit message format](/#commit-message-format) to name the Pull Request title properly. 3. Add a Pull Request description: - Add a description of changes, decisions, backstory, thinking process, and any extra information to facilitate the review process and reduce follow-ups. @@ -130,7 +130,7 @@ Once you are confident that the change is complete and ready to be merged: 6. Follow up on your PR to keep momentum; the review should happen in 24h business days. If you haven't received feedback from the reviewers after that time, check if they are available. Otherwise, it's okay to request a review from another person. 7. Once the PR has been approved, wait for the GitHub Actions to succeed and ensure there are no conflicts with the main branch. -8. Double-check the [commit message format]({{< ref "#commit-message-format" >}}) is correct. Make sure to recognize collaboration in the commit description: `Co-authored-by: `. +8. Double-check the [commit message format](/#commit-message-format) is correct. Make sure to recognize collaboration in the commit description: `Co-authored-by: `. 9. Merge your work by selecting `Squash and merge`. This will compress all the commits into one, keeping the repository's commit history clean. - If a backport is required, cherry-pick the merged commit back to the release branches it is required in. @@ -190,7 +190,7 @@ Code reviews should be completed within 24 hours of assignment (excluding weeken ### Testing -Reach out to the Quality Assurance Engineers with the work to be done as early as possible in the development process to ensure they are informed and can guide development (see more in the [Quality Assistance]({{< ref "community/contributing/code/quality-assistance" >}}) dedicated page). +Reach out to the Quality Assurance Engineers with the work to be done as early as possible in the development process to ensure they are informed and can guide development (see more in the [Quality Assistance](/community/contributing/code/quality-assistance) dedicated page). Before asking for testing support from the QA Engineers, you should test your work after performing it. Correcting a small code error, such as a typo, or adding a missing step in the testing instructions could save QA Engineers hours of work. Also, by testing your code, you may get a better sense of why you make certain common mistakes, and learn to avoid repeating them in the future. diff --git a/content/en/community/contributing/docs/style-guide.md b/content/en/community/contributing/docs/style-guide.md index e0824b63cd..68fc54fd4f 100644 --- a/content/en/community/contributing/docs/style-guide.md +++ b/content/en/community/contributing/docs/style-guide.md @@ -137,19 +137,14 @@ Connecting readers to related content in different pages is an important aspect Use `see-also` when referencing _related topics_ and use `read-more` when referencing the _same topic_ in more depth. -### Avoid broken links -To avoid broken links always use `ref` or `relref` shortcodes for internal references with the full path for the page. Check out the [Hugo documentation for cross-references](https://gohugo.io/content-management/shortcodes/#article) for more details. - -For example, `[Icon Library]({{}})` yields "[Icon Library]({{% relref "design/interface/icons" %}})". Using the full path will avoid ambiguous references if a new page of the same is created. - ### Link paragraphs, not titles -Whether using `ref` ,`relref` or inline links, do not link a title: +Do not link a title: | Do | Don't | |---|---| | ` Read more about [InnoDB here](https://en.wikipedia.org/wiki/InnoDB).` | `## [InnoDB here](https://en.wikipedia.org/wiki/InnoDB)` | -| `The [Icon Library]({{}}) has many great icons.` | `## [Icon Library]({{}})` | +| `The [Icon Library](/design/interface/icons) has many great icons.` | `## [Icon Library](/design/interface/icons)` | ## Formatting standards diff --git a/content/en/community/contributing/docs/workflow.md b/content/en/community/contributing/docs/workflow.md index 1b2ed41d1c..c9871771f6 100644 --- a/content/en/community/contributing/docs/workflow.md +++ b/content/en/community/contributing/docs/workflow.md @@ -21,7 +21,7 @@ Anyone can contribute to CHT documentation by opening an issue in the [`cht-docs ## Writing Documentation -A high degree of importance is put on consistency and usability of CHT documentation so that it is accessible and understood by a wide audience. The CHT [documentation style guide]({{< ref "community/contributing/docs/style-guide" >}}) will help to write documentation in the most consistent and useful way. +A high degree of importance is put on consistency and usability of CHT documentation so that it is accessible and understood by a wide audience. The CHT [documentation style guide](/community/contributing/docs/style-guide) will help to write documentation in the most consistent and useful way. ## Commits to GitHub @@ -53,7 +53,7 @@ In general, reviewers should: 7. Once all comments have been resolved, or changes are satisfactory, **Merge pull request** to complete the updates, and delete the branch. > [!TIP] Additional Tips for Reviewers: -> * Use the [Style Guide]({{< ref "community/contributing/docs/style-guide" >}}) to maintain documentation quality +> * Use the [Style Guide](/community/contributing/docs/style-guide) to maintain documentation quality > * Compare content to pages within the same section and encourage consistency > * Be empathetic to the author, commenting on positive aspects of PRs as well as changes > * Ask clarifying questions where needed to avoid further confusion diff --git a/content/en/community/contributing/translations.md b/content/en/community/contributing/translations.md index 52122ab1ce..3e3c113ff6 100644 --- a/content/en/community/contributing/translations.md +++ b/content/en/community/contributing/translations.md @@ -33,7 +33,7 @@ Languages marked as "Complete" are fully translated and any new user-facing text If you are interested in helping to support any of these languages, please come introduce yourself in the [Translation category](https://forum.communityhealthtoolkit.org/c/product/translations/35) on the CHT Community Forum! (No technical knowledge/experience is needed to help with translations.) -See the [localization documentation]({{< ref "building/translations/overview" >}}) for more information on how to manage custom translations for a particular CHT instance. +See the [localization documentation](/building/translations/overview) for more information on how to manage custom translations for a particular CHT instance. ## Overview @@ -59,7 +59,7 @@ In the cht-core repository, the translations are stored in [`api/resources/trans - Create a unique key to identify the translation string. The key should accurately describe the string's purpose/usage. - Add the key to each of the files contained in `api/resources/translations`. - Include an English translation string for your key (and strings for any other languages you are proficient in). Leave the string empty for the other languages. - - Note the [translation linting]({{< ref "#linting-translations" >}}) will fail for any empty strings in translation files for the languages marked as "Supported" in the table above. This is expected and the check should continue to fail until translations from the community are added (as described below). + - Note the [translation linting](/#linting-translations) will fail for any empty strings in translation files for the languages marked as "Supported" in the table above. This is expected and the check should continue to fail until translations from the community are added (as described below). - When you have completed the implementation of your new feature (and you are confident you know which translation strings are needed), make a new post in the [Translation category](https://forum.communityhealthtoolkit.org/c/product/translations/35) on the CHT Community Forum requesting help from the community to translate the new strings. - Include the key(s) and the English string(s) in your post, with a link to the issue/PR you are working on. You can also include any context/screenshots that may help the translators understand the string's purpose. - Add the additional translations from the community into the proper files in `api/resources/translations`. @@ -78,7 +78,7 @@ Much of the app is configurable (eg: forms and schedules). Because the specifics ## Modifying any existing translation values -To modify a translation string value, update the default English value and then follow the same basic steps [outlined above]({{< ref "#adding-new-keys" >}}) to request translations from the community. +To modify a translation string value, update the default English value and then follow the same basic steps [outlined above](/#adding-new-keys) to request translations from the community. ## Removing translation keys diff --git a/content/en/design/best-practices.md b/content/en/design/best-practices.md index 6b90622f0c..51341ca1bd 100644 --- a/content/en/design/best-practices.md +++ b/content/en/design/best-practices.md @@ -81,7 +81,7 @@ The screenshots here represent some of the smallest phones our users have. As yo ### Icons -The Community Health Toolkit includes a collection of [60+ free icons]({{< ref "/design/interface/icons" >}}) that represent key elements of different community health workflows and protocols. Review the recommended usages that follow. +The Community Health Toolkit includes a collection of [60+ free icons](//design/interface/icons) that represent key elements of different community health workflows and protocols. Review the recommended usages that follow. |Icon | People and Places Hierarchies | @@ -200,7 +200,7 @@ After all of the required questions in a form are answered, a summary page is di *Note: The form is not submitted until the user scrolls to the end of the page and clicks “Submit”.* -All care guides are defined using [ODK XForms](https://opendatakit.github.io/xforms-spec/), an XML definition of the structure and format for a set of questions. Since writing raw XML can be tedious, we suggest creating the forms using the [XLSForm standard](http://xlsform.org/), and using the [cht-conf](https://github.com/medic/cht-conf) command line configurer tool to convert them to XForm format. Because the XLSForms are converted directly to XForms, they essentially are the form, and so it’s important that the XLS be set up properly and consistently. Read more about configuring forms [here]({{< ref "building/forms/app">}}). +All care guides are defined using [ODK XForms](https://opendatakit.github.io/xforms-spec/), an XML definition of the structure and format for a set of questions. Since writing raw XML can be tedious, we suggest creating the forms using the [XLSForm standard](http://xlsform.org/), and using the [cht-conf](https://github.com/medic/cht-conf) command line configurer tool to convert them to XForm format. Because the XLSForms are converted directly to XForms, they essentially are the form, and so it’s important that the XLS be set up properly and consistently. Read more about configuring forms [here](/building/forms/app). #### Page Sections diff --git a/content/en/design/interface/icons/_index.md b/content/en/design/interface/icons/_index.md index 6deb45ea1e..e9c0ab07d0 100644 --- a/content/en/design/interface/icons/_index.md +++ b/content/en/design/interface/icons/_index.md @@ -27,7 +27,7 @@ Use the `forms_tasks_targets` folder to find PNG and SVG icons for application c {{< /callout >}} {{< callout type="info" >}} - Check out the [best practices]({{< ref "design/best-practices#icons" >}}) to learn more about which icons can be used for which use cases and workflows + Check out the [best practices](/design/best-practices#icons) to learn more about which icons can be used for which use cases and workflows {{< /callout >}} {{< callout type="important" icon="sparkles" >}} diff --git a/content/en/design/mapping-hierarchy.md b/content/en/design/mapping-hierarchy.md index a95aa32c93..f688957564 100644 --- a/content/en/design/mapping-hierarchy.md +++ b/content/en/design/mapping-hierarchy.md @@ -16,7 +16,7 @@ This section will take you through mapping of users on CHT hierarchy, including: ## Brief Overview of Key Concepts -A *[user persona]({{< ref "design/personas" >}})* is a generalized character that embodies a particular type of user. +A *[user persona](/design/personas)* is a generalized character that embodies a particular type of user. *User roles* are the activities that the user personas are expected to carry out. @@ -24,7 +24,7 @@ A *hierarchy* represents the reporting structure. ## Prerequisites/Required Resources -[Personas.]({{< ref "design/personas" >}}) +[Personas.](/design/personas) ## Steps diff --git a/content/en/design/user-experience-research/focus-group-discussions.md b/content/en/design/user-experience-research/focus-group-discussions.md index 1d33d0cae3..8cfa7f6049 100644 --- a/content/en/design/user-experience-research/focus-group-discussions.md +++ b/content/en/design/user-experience-research/focus-group-discussions.md @@ -19,7 +19,7 @@ Focus group discussions are a quick and convenient way to collect data from seve 4. Location 5. Mobile devices -Here is a [focused group discussion template]({{< ref "template" >}}). +Here is a [focused group discussion template](/template). ## Recruiting diff --git a/content/en/design/user-experience-research/user-interviews.md b/content/en/design/user-experience-research/user-interviews.md index 49cbfa92e0..1941595ca7 100644 --- a/content/en/design/user-experience-research/user-interviews.md +++ b/content/en/design/user-experience-research/user-interviews.md @@ -21,9 +21,9 @@ Generative interviews are used in the discovery phase of the development process 2. Personnel 3. Location, or connectivity if remote -[Here is a generative interview template]({{< ref "generative-template" >}}) +[Here is a generative interview template](/generative-template) -[Here is a scoped interview template]({{< ref "scoped" >}}) +[Here is a scoped interview template](/scoped) ## Recruiting diff --git a/content/en/hosting/SSO/_index.md b/content/en/hosting/SSO/_index.md index 3faa8c7198..acd34cd43f 100644 --- a/content/en/hosting/SSO/_index.md +++ b/content/en/hosting/SSO/_index.md @@ -27,7 +27,7 @@ SSO authentication is implemented with the industry standard [OpenID Connect](ht ## Quick Start 1. Add a new client to your OIDC Provider with the redirect URL of `https:///medic/login/oidc`. You will need your client id, client secret, and the discovery URL of your OIDC Provider for the next steps. Be sure to replace `CHT_URL` with your real URL. -2. Add the Client App ID (`APP_ID`), OIDC Provider discovery URL (`WELL_KNOWN_OIDC_URL`) and CHT URL (`CHT_URL`) to your [app_settings.json]({{< ref "building/reference/app-settings/oidc_provider" >}}) using [CHT Conf]({{< ref "technical-overview/architecture/cht-conf" >}}). Be sure to replace `APP_ID`, `WELL_KNOWN_OIDC_URL` and `CHT_URL` with your real URLs: +2. Add the Client App ID (`APP_ID`), OIDC Provider discovery URL (`WELL_KNOWN_OIDC_URL`) and CHT URL (`CHT_URL`) to your [app_settings.json](/building/reference/app-settings/oidc_provider) using [CHT Conf](/technical-overview/architecture/cht-conf). Be sure to replace `APP_ID`, `WELL_KNOWN_OIDC_URL` and `CHT_URL` with your real URLs: ```json "oidc_provider": { @@ -37,7 +37,7 @@ SSO authentication is implemented with the industry standard [OpenID Connect](ht "app_url": "https:///" ``` 3. Upload the secret from step 1 to the CHT. Be sure to replace `CHT_URL` , `USER`, `PASSWORD` and `SECRET` with the correct values: `curl -X PUT https://:@/api/v1/credentials/oidc:client-secret -H "Content-Type: text/plain" --data ""` -4. Before logging into the CHT, each SSO user must have a CHT user [provisioned with an "SSO Email Address"]({{< ref "building/reference/api/#login-by-oidc" >}}) that matches the email address configured for the user with the OIDC Provider. +4. Before logging into the CHT, each SSO user must have a CHT user [provisioned with an "SSO Email Address"](/building/reference/api/#login-by-oidc) that matches the email address configured for the user with the OIDC Provider. 5. Use the "Login with SSO" button on the CHT login page. ## Detailed guides diff --git a/content/en/hosting/SSO/technical.md b/content/en/hosting/SSO/technical.md index 4195e1bebf..694133a33d 100644 --- a/content/en/hosting/SSO/technical.md +++ b/content/en/hosting/SSO/technical.md @@ -12,7 +12,7 @@ CHT `4.20.0` introduced the single sign on (SSO) feature allowing deployments to ## Setup -Follow the [setup steps]({{< ref "/hosting/sso" >}}) to [configure your CHT instance]({{< ref "building/reference/app-settings/oidc_provider" >}}) for SSO Login. Once the server has been properly configured, the "Login with SSO" button will be visible on the CHT Login page. CHT users with the [`oidc_username` property]({{< ref "building/reference/api/#login-by-oidc" >}}) will be able to log in with their SSO credentials. The "SSO Email Address" field will be also be visible in the create/update users modal in the [App Management interface]({{< ref "building/admin/admin-overview" >}}). +Follow the [setup steps](//hosting/sso) to [configure your CHT instance](/building/reference/app-settings/oidc_provider) for SSO Login. Once the server has been properly configured, the "Login with SSO" button will be visible on the CHT Login page. CHT users with the [`oidc_username` property](/building/reference/api/#login-by-oidc) will be able to log in with their SSO credentials. The "SSO Email Address" field will be also be visible in the create/update users modal in the [App Management interface](/building/admin/admin-overview). ## User Mapping diff --git a/content/en/hosting/analytics/building-dbt-models.md b/content/en/hosting/analytics/building-dbt-models.md index 88fbc856fa..93bd9ddcb4 100644 --- a/content/en/hosting/analytics/building-dbt-models.md +++ b/content/en/hosting/analytics/building-dbt-models.md @@ -18,10 +18,10 @@ aliases: [CHT Sync](/technical-overview/architecture/cht-sync) copies data from CouchDB to a relational database. It initially stores the document data from CouchDB in a `jsonb` column in a single PostgreSQL table. This is not possible to query for analytics, so it uses [dbt](https://www.getdbt.com/) to convert the document data to a relational database format. -The [cht-pipeline repository](https://github.com/medic/cht-pipeline) defines a dbt project, which contains model files for the data schema described in the [database schema conventions]({{< ref "technical-overview/data/db-schema" >}}). +The [cht-pipeline repository](https://github.com/medic/cht-pipeline) defines a dbt project, which contains model files for the data schema described in the [database schema conventions](/technical-overview/data/db-schema). Forms may be specific to each CHT application; additional models will need to be developed to analyze data from responses to these custom forms. One additional model will be needed for each form, and for any aggregations, dashboards, or reusable views that use those form responses as input. -If using the [configurable contact hierarchy]({{< ref "building/reference/app-settings/hierarchy#app_settingsjson-contact_types" >}}), it may also be useful to add models for other contact types. +If using the [configurable contact hierarchy](/building/reference/app-settings/hierarchy#app_settingsjson-contact_types), it may also be useful to add models for other contact types. ## Prerequisites @@ -64,7 +64,7 @@ When it is necessary to update the base models, update the version tag in the de ### Testing models and dashboards -It is highly encouraged to write [dbt tests]({{< ref "/hosting/analytics/testing-dbt-models" >}}) for application-specific models to ensure that they are accurate and to avoid releasing broken models. Examples can be found in the [cht-pipeline repository](https://github.com/medic/cht-pipeline/tree/main/tests). +It is highly encouraged to write [dbt tests](//hosting/analytics/testing-dbt-models) for application-specific models to ensure that they are accurate and to avoid releasing broken models. Examples can be found in the [cht-pipeline repository](https://github.com/medic/cht-pipeline/tree/main/tests). ## Base Models @@ -101,7 +101,7 @@ The document itself is not copied to this table; to use it requires joining to t |`dbname`| The name of the CouchDB database the document was synced from. | ### `data_record` -All form responses are stored in the `data_record` table; see more details [in the database schema conventions]({{< ref "technical-overview/data/db-schema#reports" >}}). +All form responses are stored in the `data_record` table; see more details [in the database schema conventions](/technical-overview/data/db-schema#reports). This table contains columns for the contact who made the report, the parent of that contact, and the date it was reported. |Field|Description| @@ -118,7 +118,7 @@ This table contains columns for the contact who made the report, the parent of t |`grandparent_uuid`| uuid of the parent of `contact` who submitted the form (at the date `reported`; contacts parent may have changed since then, this column will not)| ### `contact` -See a description of contact documents in CouchDB [in the database schema conventions]({{< ref "technical-overview/data/db-schema#contacts-persons-and-places" >}}). +See a description of contact documents in CouchDB [in the database schema conventions](/technical-overview/data/db-schema#contacts-persons-and-places). Every person and place is stored in the `contact` table. Persons and places are stored in their own tables, but because contact types are configurable, other contact types do not have their own tables by default. The contact hierarchy defines "is a" relationships between contact types; e.g., a patient is a person is a contact. This is modeled as one table per type, where the `uuid` is both the primary key for the child table and a foreign key to the parent table. @@ -135,7 +135,7 @@ The contact hierarchy defines "is a" relationships between contact types; e.g., |`muted`| `true` if this contact has been muted| ### `contact_type` -This table stores metadata about contact types. It uses the configurable contact types from [app settings]({{< ref "building/reference/app-settings/hierarchy#app_settingsjson-contact_types" >}}), combined with all distinct values of `contact_type` from the `contact` table. +This table stores metadata about contact types. It uses the configurable contact types from [app settings](/building/reference/app-settings/hierarchy#app_settingsjson-contact_types), combined with all distinct values of `contact_type` from the `contact` table. The `person` column defines which contact types are persons and which are places. It uses the `person` field from the settings, or if the contact type is not in settings, it is assumed to be a place unless `id` is `person` |Field|Description| diff --git a/content/en/hosting/couch2pg/_index.md b/content/en/hosting/couch2pg/_index.md index dff79897da..794d3bd45f 100644 --- a/content/en/hosting/couch2pg/_index.md +++ b/content/en/hosting/couch2pg/_index.md @@ -7,7 +7,7 @@ description: > --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync]({{< ref "/hosting/analytics" >}}). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](//hosting/analytics). {{< /callout >}} {{< subpages >}} \ No newline at end of file diff --git a/content/en/hosting/couch2pg/couch2pg-oom-errors.md b/content/en/hosting/couch2pg/couch2pg-oom-errors.md index 67433e70bb..9da0e64c6e 100644 --- a/content/en/hosting/couch2pg/couch2pg-oom-errors.md +++ b/content/en/hosting/couch2pg/couch2pg-oom-errors.md @@ -10,7 +10,7 @@ aliases: --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync]({{< ref "/hosting/analytics" >}}). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](//hosting/analytics). {{< /callout >}} Some times when couch2pg is replicating documents to postgres, it encounters very large info docs that are larger than the memory allocation of the document sync array and causes out-of-memory errors. diff --git a/content/en/hosting/couch2pg/couch2pg-setup.md b/content/en/hosting/couch2pg/couch2pg-setup.md index 36a7e2e094..3edc673fcf 100644 --- a/content/en/hosting/couch2pg/couch2pg-setup.md +++ b/content/en/hosting/couch2pg/couch2pg-setup.md @@ -12,7 +12,7 @@ aliases: --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync]({{< ref "/hosting/analytics" >}}). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](//hosting/analytics). {{< /callout >}} This tutorial will take you through setting up a couch2pg service. @@ -49,7 +49,7 @@ Before you begin, you need to have some useful software and tools that are requi * [PostgreSQL](https://www.postgresql.org/) 9.4 or later ## Prerequisites -You should have a functioning [CHT instance installed locally]({{< ref "building/local-setup" >}}) +You should have a functioning [CHT instance installed locally](/building/local-setup) You should have a working database with a user that has full creation rights on the database. A database `POSTGRES_DB_NAME` and `couch2pg` user can be created and access granted using the following query: ``` diff --git a/content/en/hosting/couch2pg/migration.md b/content/en/hosting/couch2pg/migration.md index 7d1081e012..0aa5e010bd 100644 --- a/content/en/hosting/couch2pg/migration.md +++ b/content/en/hosting/couch2pg/migration.md @@ -7,7 +7,7 @@ description: > --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync]({{< ref "/hosting/analytics" >}}). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](//hosting/analytics). {{< /callout >}} ## Assumptions & Prerequisites @@ -24,7 +24,7 @@ Further, be sure you meet the following prerequisites: * Have access to couch2pg instance, including the CHT Core credentials it's using * Have 3x the disk space as your data on both the old and new server - see below -**Note:** If you don't mind waiting and don't want to deal with the trouble of copying large data files around as documented on this page, it will be easier to set up a clean [install of couch2pg]({{< ref "/hosting/couch2pg/setup-and-devlopment" >}}) +**Note:** If you don't mind waiting and don't want to deal with the trouble of copying large data files around as documented on this page, it will be easier to set up a clean [install of couch2pg](//hosting/couch2pg/setup-and-devlopment) ### Time to copy diff --git a/content/en/hosting/couch2pg/setup-and-devlopment.md b/content/en/hosting/couch2pg/setup-and-devlopment.md index 8fc8fbba36..511e790d23 100644 --- a/content/en/hosting/couch2pg/setup-and-devlopment.md +++ b/content/en/hosting/couch2pg/setup-and-devlopment.md @@ -7,7 +7,7 @@ description: > --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync]({{< ref "/hosting/analytics" >}}). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](//hosting/analytics). {{< /callout >}} Create read-only replicas of CouchDB data inside PostgresSQL. diff --git a/content/en/reference-apps/covid-rdt-reference-app.md b/content/en/reference-apps/covid-rdt-reference-app.md index 64cf8ad154..2cd7ebce54 100644 --- a/content/en/reference-apps/covid-rdt-reference-app.md +++ b/content/en/reference-apps/covid-rdt-reference-app.md @@ -43,7 +43,7 @@ For more information on these features, see the ["Related Content"](#related-con Additional requirements for this application beyond CHT 3.13, include [CHT Android 0.10.0](https://github.com/medic/cht-android) or later and Dimagi's [RD-Toolkit 0.9.8](https://github.com/dimagi/rd-toolkit/) or later. -While this application calls the RD-Toolkit, the integration features in the CHT Core and CHT Android are generic. This means you could use a different RDT Android application if you prefer. Beyond the scope of RDTs, you could use this integration feature to launch any other Android app to perform an action and save the result in the CHT. To read more about this feature, see the [Android App Launcher section in the Forms reference documentation]({{< ref "building/forms/app#android-app-launcher" >}}). +While this application calls the RD-Toolkit, the integration features in the CHT Core and CHT Android are generic. This means you could use a different RDT Android application if you prefer. Beyond the scope of RDTs, you could use this integration feature to launch any other Android app to perform an action and save the result in the CHT. To read more about this feature, see the [Android App Launcher section in the Forms reference documentation](/building/forms/app#android-app-launcher). ## Workflow @@ -56,7 +56,7 @@ There are three main components to this application: ## Training Materials -Medic is providing images and videos for use in training CHWs on how to use the CHT with the RD-Toolkit. These could be combined with existing in [app training]({{< ref "reference-apps/covid-education" >}}) if needed. As well, the RD-Toolkit has in app instructions for how to use specific RDTs. +Medic is providing images and videos for use in training CHWs on how to use the CHT with the RD-Toolkit. These could be combined with existing in [app training](/reference-apps/covid-education) if needed. As well, the RD-Toolkit has in app instructions for how to use specific RDTs. ### Images @@ -90,16 +90,16 @@ This second video shows the right side of the workflow above to capture RDT resu Like all applications written for the CHT, there are built-in mechanisms to retrieve raw and aggregate data to generate reports and dashboards. Here are some ways that the data can be accessed: - * **[In app targets]({{< ref "building/targets/targets-overview" >}}):** Gives the CHW or their supervisor an aggregate view of any of the form fields. Since targets rely on the data on the device, if targets include data from other users then permissions must be set on the relevant forms so that the data can be replicated and synchronized accordingly. - * **API Calls:** Given that all form submissions are captured in JSON and that we know the data model well, you can easily do API calls to a CHT server instance and use some custom code (node, python etc) to gather and show stats on a daily basis. You can export to either JSON or CSV. See API docs [for reports]({{< ref "building/reference/api#get-apiv2exportreports" >}}) as well as [monitoring metadata]({{< ref "building/reference/api#get-apiv2monitoring" >}}). + * **[In app targets](/building/targets/targets-overview):** Gives the CHW or their supervisor an aggregate view of any of the form fields. Since targets rely on the data on the device, if targets include data from other users then permissions must be set on the relevant forms so that the data can be replicated and synchronized accordingly. + * **API Calls:** Given that all form submissions are captured in JSON and that we know the data model well, you can easily do API calls to a CHT server instance and use some custom code (node, python etc) to gather and show stats on a daily basis. You can export to either JSON or CSV. See API docs [for reports](/building/reference/api#get-apiv2exportreports) as well as [monitoring metadata](/building/reference/api#get-apiv2monitoring). * **[PostgreSQL queries](https://github.com/medic/cht-sync):** CHT ships with a utility to export all the data that the API has to a relational database, Postgres. You have all the raw data the API has, but can now use the power of joins and groupings to come up with totally customizable stats by day, week, month etc. Data can be synched near real time from the CHT. * **Dashboards:** Medic has used both [Klipfolio](https://www.klipfolio.com/) and, more recently, [Superset](https://superset.incubator.apache.org/) to create more complex yet still user-friendly dashboards. This is particular useful for those who need to view the data but wouldn't otherwise be logging in to CHT apps. These dashboards generally access the relational data in the Postgres database as the back end. - * **Third-Party Applications:** Connecting to third-party applications can be done using built-in [integrations]({{< ref "building/integrations" >}}), or building a workflow with [custom integrations]({{< ref "building/integrations/custom" >}}). + * **Third-Party Applications:** Connecting to third-party applications can be done using built-in [integrations](/building/integrations), or building a workflow with [custom integrations](/building/integrations/custom). ### Sample API call -Start with finding out the names of the forms you can get reports from. If you had deployed this application without any customizations, you would have these forms available as seen by calling the [forms API]({{< ref "building/reference/api#get-apiv1forms" >}}): +Start with finding out the names of the forms you can get reports from. If you had deployed this application without any customizations, you would have these forms available as seen by calling the [forms API](/building/reference/api#get-apiv1forms): ```shell curl "http://LOGIN:PASSWORD@HOSTNAME/api/v1/forms" | jq @@ -122,7 +122,7 @@ The resulting JSON is formatted by `jq` for you to get an easy to read list. ] ``` -The last two forms can be used to query [the reports API ]({{< ref "building/reference/api#get-apiv2exportreports" >}}) to get RDT provions and captures. To get all the capture reports into a file called `output.csv`, you would use this call: +The last two forms can be used to query [the reports API ](/building/reference/api#get-apiv2exportreports) to get RDT provions and captures. To get all the capture reports into a file called `output.csv`, you would use this call: ```shell curl "http://LOGIN:PASSWORD@HOSTNAME/api/v2/export/reports?filters[search]=&filters[forms][selected][0][code]=covid19_rdt_capture" > output.csv @@ -171,7 +171,7 @@ These are the files in the COVID-19 app where you'll want to focus your customiz The `forms/app/covid19_rdt_provision` and `forms/app/covid19_rdt_capture` forms (`xlsx`, `xml` and `properties.json`) represent the provision and capture portions of the forms. The tasks that get created are defined in `tasks.js`. Not shown are standard contact definitions in `forms/contact/*` as well as supporting configurations for icons and other CHT application settings. -To read more about how these files all work together, see [app forms]({{< ref "building/forms/app" >}}), [contact forms]({{< ref "building/forms/contact" >}}), and [task]({{< ref "building/tasks/tasks-js" >}}) reference documentation +To read more about how these files all work together, see [app forms](/building/forms/app), [contact forms](/building/forms/contact), and [task](/building/tasks/tasks-js) reference documentation ## Example form submission diff --git a/content/en/reference-apps/direct-to-client.md b/content/en/reference-apps/direct-to-client.md index 8a59c1405e..ecca3d714c 100644 --- a/content/en/reference-apps/direct-to-client.md +++ b/content/en/reference-apps/direct-to-client.md @@ -63,7 +63,7 @@ Clients are enrolled directly using the CHT D2C, 2wT app using a phone, tablet o {{< figure src="Figure1SystemArchitecture.jpg" link="Figure1SystemArchitecture.jpg" alt="Direct Messaging technical architecture" title="" caption="**Figure 1:** System architecture of direct-to-client (D2C), two-way texting (2wT) for voluntary medical male circumcision (VMMC) postoperative care. API: application programming interface; CHT: Community Health Toolkit." class="left col-10">}} -The CHT core framework has inbuilt [privacy/security features]({{< ref "building/privacy-policies" >}}) including two- factor authentication, role based authorization, data security, and a range of protected data access endpoints. The system can be configured to manage [user roles and permissions]({{< ref "building/users" >}}) for access of CHT applications. Responsible data practices is enforced through the [Privacy and Data Protection Policy]({{< ref "building/privacy-policies" >}}). +The CHT core framework has inbuilt [privacy/security features](/building/privacy-policies) including two- factor authentication, role based authorization, data security, and a range of protected data access endpoints. The system can be configured to manage [user roles and permissions](/building/users) for access of CHT applications. Responsible data practices is enforced through the [Privacy and Data Protection Policy](/building/privacy-policies). The D2C, 2wT app incorporates the CHT security features in order to protect client data and ensure the confidentiality and privacy of client information. Users are encouraged to use password protected user accounts, the app also has full disk encryption and auto-lock screens for users’ devices (android phones and tablets) in order to minimize the risk of unwarranted access. Role based access controls also make sure that users can only view and edit information that the permissions assigned to the user role allow them to. diff --git a/content/en/reference-apps/learning-care.md b/content/en/reference-apps/learning-care.md index 86f53c7c0e..7c7053688f 100644 --- a/content/en/reference-apps/learning-care.md +++ b/content/en/reference-apps/learning-care.md @@ -30,7 +30,7 @@ With the spread of COVID-19, it is imperative that access to learning, integrate The Community Health Academy and Medic set out to deliver a fully-integrated Learning and Care solution, with targeted COVID-19 learning experiences as a global public good. -This integrated Learning & Care App leverages the **[remote onboarding]({{< ref "reference-apps/training" >}}), [task & scheduling]({{< ref "building/tasks" >}}), and [target]({{< ref "building/targets/targets-overview" >}}) features** of the CHT core framework with the **curated, multimedia educational content** from the Academy’s COVID-19 library. +This integrated Learning & Care App leverages the **[remote onboarding](/reference-apps/training), [task & scheduling](/building/tasks), and [target](/building/targets/targets-overview) features** of the CHT core framework with the **curated, multimedia educational content** from the Academy’s COVID-19 library. ## Users and Hierarchy Example diff --git a/content/en/reference-apps/maternal-newborn.md b/content/en/reference-apps/maternal-newborn.md index 8f71b73784..ca8749ebdb 100644 --- a/content/en/reference-apps/maternal-newborn.md +++ b/content/en/reference-apps/maternal-newborn.md @@ -102,6 +102,6 @@ Both maternal and newborn care workflows are defined to connect form actions and Here are a few additional resources to help get you started with the maternal and newborn health reference application. - View the [configuration code for this reference app](https://github.com/medic/cht-core/tree/master/config/default/) -- Install the reference app following these [easy installation instructions]({{< ref "building/local-setup" >}}) -- Modify the maternal and newborn reference application for your project context using [configuration best practices]({{< ref "design/best-practices" >}}) +- Install the reference app following these [easy installation instructions](/building/local-setup) +- Modify the maternal and newborn reference application for your project context using [configuration best practices](/design/best-practices) - Understand the basis for measuring the impact of maternal and newborn workflows by reviewing the World Health Organization's [Core Health Indicators](https://www.who.int/data/gho/data/indicators/indicators-index) diff --git a/content/en/reference-apps/pharmacovigilance-reference-app.md b/content/en/reference-apps/pharmacovigilance-reference-app.md index 976827b4aa..9e66d4876a 100644 --- a/content/en/reference-apps/pharmacovigilance-reference-app.md +++ b/content/en/reference-apps/pharmacovigilance-reference-app.md @@ -60,8 +60,8 @@ A CHP uses the assessment form to report a death caused by an adverse drug react Here are a few additional resources to help get you started with the pharmacovigilance health reference application. - View the [configuration code for this reference app](https://github.com/medic/cht-accelerator/tree/main/IntelliSOFT/Example%20CHT%20application/cht_pvers) -- Install the reference app following these [easy installation instructions]({{< ref "building/local-setup" >}}) -- Modify the pharmacovigilance reference application for your project context using [configuration best practices]({{< ref "design/best-practices" >}}) +- Install the reference app following these [easy installation instructions](/building/local-setup) +- Modify the pharmacovigilance reference application for your project context using [configuration best practices](/design/best-practices) The open sharing of digital health apps used by CHWs is a monumental milestone in the digital health space, and for the CHT Community. Reach out on the [forum](https://forum.communityhealthtoolkit.org/) to share how you will leverage these resources, along with your feedback and continued innovations that could benefit the larger community. diff --git a/content/en/reference-apps/pih.md b/content/en/reference-apps/pih.md index fadb2822f4..54e322550a 100644 --- a/content/en/reference-apps/pih.md +++ b/content/en/reference-apps/pih.md @@ -286,7 +286,7 @@ The Human Immunodeficiency Virus (HIV) workflow is designed to guide CHWs in HIV Here are a few additional resources to help get you started with the integrated health reference application. - View the [configuration code for this reference app](https://github.com/medic/cht-pih-malawi-app) -- Install the reference app following these [easy installation instructions]({{< ref "building/local-setup" >}}) -- Modify the maternal and newborn reference application for your project context using [configuration best practices]({{< ref "design/best-practices" >}}) +- Install the reference app following these [easy installation instructions](/building/local-setup) +- Modify the maternal and newborn reference application for your project context using [configuration best practices](/design/best-practices) The open sharing of digital health apps used by CHWs is a monumental milestone in the digital health space, and for the CHT Community. Reach out on the [forum](https://forum.communityhealthtoolkit.org/) to share how you will leverage these resources, along with your feedback and continued innovations that could benefit the larger community. diff --git a/content/en/releases/2_13_0.md b/content/en/releases/2_13_0.md index 038dd9c41f..92f1388c57 100644 --- a/content/en/releases/2_13_0.md +++ b/content/en/releases/2_13_0.md @@ -13,8 +13,8 @@ aliases: ## Migration notes -- [#2635](https://github.com/medic/cht-core/issues/2635) changes the context available to the configured contact summary script. The `contact` parameter no longer has information about parents. This information is now in an array called `lineage`. More information is available in the [configuration documentation]( {{< relref "building/contact-summary/contact-summary-overview" >}} ). -- [#3546](https://github.com/medic/cht-core/issues/3546) changes the implementation of the `contact_summary` so instead of declaring the output on the last line of the script, now you have to return the output. Usually this is as easy as adding a return on the last line, so `output;` becomes `return output;`. More information is available in the [configuration documentation]( {{< relref "building/contact-summary/contact-summary-overview" >}} ). +- [#2635](https://github.com/medic/cht-core/issues/2635) changes the context available to the configured contact summary script. The `contact` parameter no longer has information about parents. This information is now in an array called `lineage`. More information is available in the [configuration documentation](/building/contact-summary/contact-summary-overview). +- [#3546](https://github.com/medic/cht-core/issues/3546) changes the implementation of the `contact_summary` so instead of declaring the output on the last line of the script, now you have to return the output. Usually this is as easy as adding a return on the last line, so `output;` becomes `return output;`. More information is available in the [configuration documentation](/building/contact-summary/contact-summary-overview). ## Features diff --git a/content/en/releases/2_16_0.md b/content/en/releases/2_16_0.md index 456702f992..cb97600551 100644 --- a/content/en/releases/2_16_0.md +++ b/content/en/releases/2_16_0.md @@ -1,261 +1,261 @@ ---- -title: "2.16.0 release notes" -linkTitle: "2.16.0" -sidebar: - exclude: true -description: - Released 2018-07-04 - -aliases: - - /core/releases/2.16.0 - - /releases/2.16.0 ---- - -## What's New - -### View date last visited for places on the people tab - -_Because knowing where you've been helps you know where you're going next! - Medic proverb_ - -In order to help CHWs achieve full coverage of every family or household they care for, we've added an optional feature to update the list of families or areas to display the date that family or area was last visited. You can use any patient- or family-level form or forms to update the date last visited. You may run into performance issues if you configure this to look at forms submitted very frequently. For example, we expect five forms submitted only once a month to work better than two forms submitted every day. Make sure you test! - -{{< figure src="../images/2_16_0-4526-1.png" link="../images/2_16_0-4526-1.png" caption="Screenshot" >}} - -In order to see the date last visited instead of the primary contact, make sure you give your CHWs (or whichever users need to see date last visited) the `can_view_last_visited_date` permission. Once that permission is enabled, you'll be able to display the date the family was last visited in the list. Make sure you have this permission enabled in `app_settings` to avoid overwriting the permission when you upload your config: - -```javascript -{ - "name": "can_view_last_visited_date", - "roles": [ - "chw", - "district_admin" - ] -} -``` - -When you first implement this, you'll see a long list of "Last visit unknown". You'll need to indicate which forms should be included in the calculation for the date last visited. You can use forms at the person or family level, though it is preferable to limit the number of forms included to the minimal number to avoid performance issues. - -Indicating that a form should be included in the calculation for the date last visited is as simple as adding a field called `visited_contact_uuid` to your form. This should be a `calculate` field that contains the family/household (`clinic` level place) UUID. Make sure this is a top-level field (not in any group and will be in `doc.fields.visited_contact_uuid` when you submit). To test, upload your form with this field, fill it out and submit, and your people list will update with the correct relative date. Note that you may need to refresh the people tab by either clicking refresh or navigating to another tab and then back. - -Example XLSForm (this is a patient-level form): - -{{< figure src="../images/2_16_0-4526-2.png" link="../images/2_16_0-4526-2.png" caption="Screenshot" >}} - -[[#4526](https://github.com/medic/cht-core/issues/4526)] - -### Sort places by date last visited - -_Puts the households who haven't been seen in the longest time at the top, because you know how you hated it in school when the kids whose last names ended in "A" always got to be first in line?_ - -When you enable the permission to see the date last visited in the people tab list, you will notice that a new icon appears in the top bar. This icon is for sorting the list of people. The default sort is alphabetical, as you have probably noticed. The new icon allows you to sort your families or households by the date last visited. You will need to enable the permission for viewing the date last visited and configure one or more forms to be included in the calculation of the last visit date for each family ([see previous section](#view-date-last-visited-for-places-on-the-people-tab)). Once you've done that, the sort will just work. By default, when you sort by "date last visited," the households you saw _least_ recently will be at the top, gradually increasing to those you saw most recently. Because you know, you should prioritize the households who haven't been seen in the longest amount of time. - -Fun fact: We drew this feature for the first time while chatting about visit practices in a workshop with LG CHPs in Uganda. See the drawings on the lower right that shows a family list being reordered by date, with those visited least recently at the top. - -{{< figure src="../images/2_16_0-4524-1.jpg" link="../images/2_16_0-4524-1.jpg" caption="Image" >}} - -{{< figure src="../images/2_16_0-4524-2.png" link="../images/2_16_0-4524-2.png" caption="Comparison" >}} - -[#4524](https://github.com/medic/cht-core/issues/4524) - -### Toggle Universal Health Coverage mode on and off - -_We're not trying to play bi-partisan politics, we're just trying to test some new features._ - -Showing the date last visited and being able to sort contacts by the date they were last visited by a CHW are the first two features designed to achieve Universal Health Coverage (UHC). While the world is quickly catching onto the importance of this, we know that not all programs are ready to implement this approach. Feature #4525 makes it possible to turn these UHC features on or off. It's still very early in our UHC design process so we'll be closely monitoring these features and conduct feedback sessions, so the UHC features previously described may still undergo some iteration. Check on the status of these features before implementing them in your project. - -[As was described earlier](#view-date-last-visited-for-places-on-the-people-tab), enabling UHC mode is as simple as giving a user the permission `can_view_last_visited_date`. This will give the user the last visit date in the people list and the ability to sort by the last visit date. Make sure you add the needed field to the forms you want to include as part of the last visit date calculation to avoid having a long list of "Last visit unknown". Once CHWs start submitting these forms, the dates on the list will slowly update. - -{{< figure src="../images/2_16_0-4525.png" link="../images/2_16_0-4525.png" caption="Comparison" >}} - -[[#4525](https://github.com/medic/cht-core/issues/4525)] - -### Expand use of the verify button for manager review of CHW reports - -_The exciting world of data cleaning just got better._ - -We've created a new and improved verification workflow for managers. Before, we just had two states for each report, verified and unverified. A report was verified by clicking the verify button. - -{{< figure src="../images/2_16_0-4529-1.png" link="../images/2_16_0-4529-1.png" caption="Comparison" >}} - -With the new feature, clicking on the verify button opens a small menu with two options: Correct and Has errors. This allows a manager to review a report and mark it correct if it looks good and mark it as having errors if they need to follow up with the CHW for further verification. The status will also be synced to the CHW's phone so they can see which reports were marked correct by their manager and which were marked as having errors. - -[With our new configurable roles](#ability-to-add-more-user-roles), it is also possible for managers to have the ability to review reports while preventing CHWs from having this option, even if both are restricted/offline-first users. - -This feature was built to support the mRDT error-checking workflow for the Muso Innovation Network. Supervisors must log in to view photos of the mRDTs ([built in 2.14.0](https://docs.google.com/document/d/1uXSqntenhxlGOeFtP7ScLcFmoid3kagPYn-EDoodP3s/edit#heading=h.4bwl8oo2mtpi)) and check that the diagnosis reported by the CHW matches the photos. If the supervisor sees an error, they can now use this feature to mark it as such. Error rates are part of the CHW's performance metrics so supervisors can see which CHWs are in need of additional training on implementing mRDTs. To complement this workflow, we built a widget on the CHP's Targets page to accompany this workflow that tracks their monthly error rate. - -{{< figure src="../images/2_16_0-4529-2.png" link="../images/2_16_0-4529-2.png" caption="Comparison" >}} - -[[#4529](https://github.com/medic/cht-core/issues/4529)] - -### Allow supervisors to review specific patient reports - -_We call this feature Super-Vision! Supervisors now have the magical ability to see reports about patients without being able to view the patients themselves. #superpowers-for-supervisors_ - -Apart from Standard, where we have very small numbers of users, supervisors are not able to view all patient reports due to device storage limits and app performance issues. However, there may be times when there are specific reports about patients that supervisors need to see, review, or take action on. This feature is not meant to allow supervisors to view all patient reports about every patient and it does not give supervisors the ability to see patient profiles. It is meant to better support workflows like reviewing mRDT images or confirming death reports. Currently, if a supervisor wanted to review an mRDT image in a patient assessment form or get a death confirmation task, she would need to have access to the patient. With this new feature, the supervisor only needs access to the patient assessment form or the death report form in order to do the review or receive the task. - -Below you'll see the Reports page from the supervisor's view. In this example, the supervisor has access to families and family reports, but does not have access to patients. Using this feature, we've configured it so that the supervisor **does** have access to patient assessment forms so that they can be reviewed, even though she doesn't have access to the patients themselves. As you can see in the screenshots below, the CHW has access to all patient- and family-level reports while the supervisor has access to all family-level reports AND the patient assessment report, but no other patient-level reports. - -{{< figure src="../images/2_16_0-4591-1.png" link="../images/2_16_0-4591-1.png" caption="Comparison" >}} - -If you want a report submitted by the CHW about a patient to be viewable by the supervisor, you'll need to make sure that the supervisor has access to families (`replication_depth` of 2 in most cases) but no access to patients. You will also need to add a field to the patient-level form that the supervisor needs access to. The field should be a `hidden` field called `needs_signoff` that must be set to true in cases where the report needs to be reviewed by a manager. For example, if you only wanted a manager to review patient assessments where an mRDT was conducted, come up with a conditional statement to set the variable to true only for assessments where the mRDT was done. This hidden field must be a top-level field (not in any group and will be in `doc.fields.needs_signoff` when you submit). To test, upload your form with this field, fill it out and submit. Log in as a user who is the supervisor of the CHW who submitted the form and make sure you are able to see the form you just submitted. - -Example XLSForm: -{{< figure src="../images/2_16_0-4591-2.png" link="../images/2_16_0-4591-2.png" caption="XLSForm" >}} - -[[#4591](https://github.com/medic/cht-core/issues/4591)] - -### Add new statuses to the status filter on the reports page - -_Because even Superheros could use some help organizing their Inbox._ - -With the [new feature that allows managers to review reports](#expand-use-of-the-verify-button-for-manager-review-of-chw-reports), we've updated the status filter to help managers easily find reports they need to review or reports they marked as having errors that need follow up. With these changes, we have retained the ability to filter by valid and invalid SMS reports. Here's what happens when you select each of these filter options: - -* **Manager review - "Not reviewed":** displays all valid reports (SMS and app) that have not been marked as correct or having errors by a manager -* **Manager review - "Reviewed: errors":** displays all reports (app or SMS) that were marked as having errors by a manager -* **Manager review - "Reviewed: correct":** displays all reports (app or SMS) that were marked as correct by a manager -* **SMS validity - "Valid SMS":** displays all SMS reports that were valid when received (regardless of whether they are "Not reviewed", "Reviewed: errors", or "Reviewed: correct") -* **SMS validity - "Invalid SMS":** displays all SMS reports that were invalid when received and have red dots (applied automatically) - -For example, if a manager wanted to review any recent patient assessments that they might have access to, she would filter by the patient assessment form type and the "Manager review - Not reviewed" status filter. This would give a list of assessment forms that have not yet been reviewed. - - -{{< figure src="../images/2_16_0-4577-1.png" link="../images/2_16_0-4577-1.png" caption="Comparison" >}} - -#### Before -{{< figure src="../images/2_16_0-4577-2.png" link="../images/2_16_0-4577-2.png" caption="Screenshot" >}} - -#### After -{{< figure src="../images/2_16_0-4577-3.png" link="../images/2_16_0-4577-3.png" caption="Screenshot" >}} - - -[[#4577](https://github.com/medic/cht-core/issues/4577)] - -### Use family equity score in tasks and actions about family members - -_Jokes aside, this features is an important step in being able to deliver a preferential option for the poor. Read more about this here: [https://www.pih.org/article/in-the-company-of-the-poor](https://www.pih.org/article/in-the-company-of-the-poor)_ - -Last year, we began implementing an equity survey in Kenya that determines a household's wealth quintile based on a number of questions about their home, possessions, and access to safe drinking water, among other things. Although the wealth quintile could be used to generate tasks for the household, we wanted to make the equity quintile useful in targeting interventions at the patient level. With this feature, we're now able to use the equity score to generate specific tasks about patients, such as increasing the number of pregnancy follow-ups for women in poorer households. We're also able to display specific notes or questions within forms for patients in lower wealth quintiles, such as asking additional questions about children in poorer households when they are being screened for malnutrition. This feature makes the equity score more usable in patient workflows and is the first step toward greater targeting of services. - -We're still learning how to deliver this feature well. We've heard from CHWs that they resist the approach that some families in their community would be "labeled" as poor in the app, even if they acknowledge that they prioritize these families differently in their daily workflows. Though this feature allows that "labeling" to happen on the backend, it may be helpful and important for a CHW to know why a family or patient has been asked these additional questions or given more frequent home visits. The Impact and Design teams are currently getting feedback on appropriate options. Consult your designer and share back what you're thinking and trying so we can all learn together! - -The feature works by pulling specific fields from a form filled at the family level and copying them to the profile of each family member in the household. For now, we are limited to the national quintile and the urban quintile. We don't pull the raw scores, just the quintiles, which are easier to use in tasks and forms. To make sure your quintiles get copied, simply make sure that you have fields called `NationalQuintile` and `UrbanQuintile` defined as top-level fields in the form you're using at the household level. These must end up at `doc.fields.NationalQuintile` and `doc.fields.UrbanQuintile` for this feature to work correctly. - -#### Sample XLSForm -{{< figure src="../images/2_16_0-4700.png" link="../images/2_16_0-4700.png" caption="XLSForm" >}} - -[[#4600](https://github.com/medic/cht-core/issues/4600)] - -### Ability to add more user roles - -_Because CHW Janet, CHW Supervisor Ann, and Paul the Data Guy don't wear the same hat in real life and now they don't have to in the app, either._ - -In order to make it possible to show the UHC mode features for some CHWs and not others, we decided to go ahead and implement configurable user roles. Up until now, we were limited to one user role for users that need offline access to their data. You have probably heard of the "restricted" user - this is the user type that allowed a CHW or manager to access data offline. However, this was limiting because every user that had offline data access had to have the same set of permissions. So, for example, a CHW and a supervisor had to have the same set of permissions, requiring both to have the permission to do something (such as delete reports) or neither would have permission to do it. This led to restrictions in what supervisors could do in order to avoid giving too many permissions to CHWs. - -With 2.16.0, we now have configurable roles! This means that a CHW and a supervisor can both access data offline but can have unique roles so that they can have different permissions. For example, a CHW might not be able to delete data, review reports, or bulk delete, but a supervisor could be given the ability to do one or more of these actions without affecting the permissions of the CHW. - -New roles can be created in the configuration pages. Instead of a permissions page, we now have a roles & permissions page. On this page we have a new tab for creating and managing user roles. Creating a new user role is as simple as creating a name and translation key for the user role and making sure you select the "Offline" checkbox if this user type needs access to data offline. - -{{< figure src="../images/2_16_0-4525-1.png" link="../images/2_16_0-4525-1.png" caption="Screenshot" >}} - -The permissions page has also been updated to better accommodate a greater number of roles. We've changed the layout to a new format. This layout is temporary for now and we expect to improve it later in the year. You can see in this example that we now have roles for Supervisor, CHW and Online User, but you can create as many roles as you need, both for users that need access to data offline and for those accessing the app online. - -{{< figure src="../images/2_16_0-4525-2.png" link="../images/2_16_0-4525-2.png" caption="Screenshot" >}} - -[[#4525](https://github.com/medic/cht-core/issues/4525)] - -### Changed use of colored dot on the reports page - -_Seeing spots? Or do we mean dots? Either way, you're about to see a whole lot less of them. If they don't go away, consult a tech lead or your family eye doctor._ - -Our use of the controversial "green dot" and "red dot" on the reports page hearkens back to the days when 100% of Medic users where using SMS. It was a quick way to see which reports were valid and which were not. Once we started having users on the mobile app, this feature became less useful because every single report was valid. This is because we have more control over how the data is entered and do not rely on the end user entering a valid Medic ID. We decided to modernize our use of red and green dots so that they make more sense across our SMS and app projects. Here's our new approach: - - -* We've removed the green dot completely from valid incoming reports. No dot = all good here = no attention needed. This is regardless of whether it came from the mobile app, a TextForm, or Medic Collect. -* Without green dots on every report, red and green dots now have more meaning. Using our new manager review feature (#4529), a manager can now use a green dot to indicate that a form is correct, and a red dot if it contains an error. -* We also know that it's important to be able to see invalid reports coming in over SMS, either TextForms or Collect forms. For these invalid SMS reports, the red dot with an "x" is automatically applied. You can filter to see all invalid SMS reports by using the status filter dropdown. Here's a summary of how the red and green dots now work: - -{{< figure src="../images/2_16_0-4574-1.png" link="../images/2_16_0-4574-1.png" caption="Comparison" >}} - -Here's a look at the reports list so you can see the before and after: - -{{< figure src="../images/2_16_0-4574-2.png" link="../images/2_16_0-4574-2.png" caption="Comparison" >}} - -The screenshot on the left shows the current use of dots for an SMS project. On a mobile app project, there's a green dot on every report. - -In the screenshot on the right, we've removed the green dots from valid reports. The green dot can be applied when a supervisor has reviewed a report and marked it correct. The red dot for invalid SMS reports is still automatically applied. Additionally, a supervisor can review a report and apply the red dot if the report has errors. - -The supervisor review feature is optional and should only be encouraged if it's part of their workflow. It's also perfectly fine for supervisors to use it selectively - to only mark reports with errors or to only review certain reports (such as mRDT, but not child assessments). The intention isn't to give supervisors more review work but to reduce the noise on the Reports page and make the information that gets shown there more meaningful. - -[[#4574](https://github.com/medic/cht-core/issues/4574)] - -### Updated header for reports - -_UI fairy dust alert! We made viewing reports on mobile prettier._ - -We've updated the header when you're viewing reports in the Reports page. The new design works much better on smaller screens: - -* We've removed the detailed date -* We've moved the relative date to the left side, below the sender name. -* If you hover over the relative date, the full date and exact time the report was received will appear. If you're on a touchscreen, do a long tap on the relative date to see the detailed date. -* If a manager has reviewed this report and marked it correct or marked it as having errors, the green or red dot would appear at the top right. - -{{< figure src="../images/2_16_0-4576-1.png" link="../images/2_16_0-4576-1.png" caption="Comparison" >}} - -#### Before - -{{< figure src="../images/2_16_0-4576-2.png" link="../images/2_16_0-4576-2.png" caption="Screenshot" >}} - -#### After - -{{< figure src="../images/2_16_0-4576-3.png" link="../images/2_16_0-4576-3.png" caption="Screenshot" >}} - -[[#4576](https://github.com/medic/cht-core/issues/4576)] - -### Allow death confirmation form to specify the date of death - -_Because the only thing worse than getting your birthday wrong is…_ - -In 2.15.0, [we added support for death reporting workflows]( {{< relref "releases/2_15_0.md#death-reporting" >}} ). One glitch we realized was that the date of death was being set to the date that the death confirmation form was submitted. With 2.16.0, we've added an improvement to the workflow. It's now possible to set a specific date of death in your death confirmation form. This makes the workflow more flexible by allowing a nurse to enter the confirmed date of death in the death confirmation form. - -In order to include a user-selected date of death as the official date of death listed in the Medic app, you'll need to make sure there is a field in the death confirmation form that lists the exact date of death and then indicate in your `app_settings` that this field should be used for the date of death. - -Example XLSForm with `date_of_death` field: - -{{< figure src="../images/2_16_0-4636.png" link="../images/2_16_0-4636.png" caption="Screenshot" >}} - -Example `app_settings` configuration: - -```javascript -"transitions": { - "death_reporting": true -}, -"death_reporting": { - "mark_deceased_forms": [ - "death_confirmation" - ], - "undo_deceased_forms": [ - "undo_death" - ], - "date_field": "fields.date_of_death" -} -``` - -[[#4636](https://github.com/medic/cht-core/issues/4636)] - - -## Bug Fixes - - -### Updated google-libphonenumber - -_Now you can change your number to avoid your ex without missing a single Medic reminder._ - -We've updated to the latest google-libphonenumber to make sure our app will accept new phone numbers across all of the countries where we work. The current version is 3.1.8. [[#4665](https://github.com/medic/cht-core/issues/4665)] - - -### Fixed a performance issue with loading contacts - - -_CHWs see a lot of people every day. That's a lot of searching! We've improved search performance by 30% which really adds up._ - -Loading contacts is now done with an `allDocs` request instead of using custom views. This improves performance of searching on the people tab and on the reports tab. It's a workaround for now as we look further into the root cause of the slowness. [[#4666](https://github.com/medic/cht-core/issues/4666)] +--- +title: "2.16.0 release notes" +linkTitle: "2.16.0" +sidebar: + exclude: true +description: + Released 2018-07-04 + +aliases: + - /core/releases/2.16.0 + - /releases/2.16.0 +--- + +## What's New + +### View date last visited for places on the people tab + +_Because knowing where you've been helps you know where you're going next! - Medic proverb_ + +In order to help CHWs achieve full coverage of every family or household they care for, we've added an optional feature to update the list of families or areas to display the date that family or area was last visited. You can use any patient- or family-level form or forms to update the date last visited. You may run into performance issues if you configure this to look at forms submitted very frequently. For example, we expect five forms submitted only once a month to work better than two forms submitted every day. Make sure you test! + +{{< figure src="../images/2_16_0-4526-1.png" link="../images/2_16_0-4526-1.png" caption="Screenshot" >}} + +In order to see the date last visited instead of the primary contact, make sure you give your CHWs (or whichever users need to see date last visited) the `can_view_last_visited_date` permission. Once that permission is enabled, you'll be able to display the date the family was last visited in the list. Make sure you have this permission enabled in `app_settings` to avoid overwriting the permission when you upload your config: + +```javascript +{ + "name": "can_view_last_visited_date", + "roles": [ + "chw", + "district_admin" + ] +} +``` + +When you first implement this, you'll see a long list of "Last visit unknown". You'll need to indicate which forms should be included in the calculation for the date last visited. You can use forms at the person or family level, though it is preferable to limit the number of forms included to the minimal number to avoid performance issues. + +Indicating that a form should be included in the calculation for the date last visited is as simple as adding a field called `visited_contact_uuid` to your form. This should be a `calculate` field that contains the family/household (`clinic` level place) UUID. Make sure this is a top-level field (not in any group and will be in `doc.fields.visited_contact_uuid` when you submit). To test, upload your form with this field, fill it out and submit, and your people list will update with the correct relative date. Note that you may need to refresh the people tab by either clicking refresh or navigating to another tab and then back. + +Example XLSForm (this is a patient-level form): + +{{< figure src="../images/2_16_0-4526-2.png" link="../images/2_16_0-4526-2.png" caption="Screenshot" >}} + +[[#4526](https://github.com/medic/cht-core/issues/4526)] + +### Sort places by date last visited + +_Puts the households who haven't been seen in the longest time at the top, because you know how you hated it in school when the kids whose last names ended in "A" always got to be first in line?_ + +When you enable the permission to see the date last visited in the people tab list, you will notice that a new icon appears in the top bar. This icon is for sorting the list of people. The default sort is alphabetical, as you have probably noticed. The new icon allows you to sort your families or households by the date last visited. You will need to enable the permission for viewing the date last visited and configure one or more forms to be included in the calculation of the last visit date for each family ([see previous section](#view-date-last-visited-for-places-on-the-people-tab)). Once you've done that, the sort will just work. By default, when you sort by "date last visited," the households you saw _least_ recently will be at the top, gradually increasing to those you saw most recently. Because you know, you should prioritize the households who haven't been seen in the longest amount of time. + +Fun fact: We drew this feature for the first time while chatting about visit practices in a workshop with LG CHPs in Uganda. See the drawings on the lower right that shows a family list being reordered by date, with those visited least recently at the top. + +{{< figure src="../images/2_16_0-4524-1.jpg" link="../images/2_16_0-4524-1.jpg" caption="Image" >}} + +{{< figure src="../images/2_16_0-4524-2.png" link="../images/2_16_0-4524-2.png" caption="Comparison" >}} + +[#4524](https://github.com/medic/cht-core/issues/4524) + +### Toggle Universal Health Coverage mode on and off + +_We're not trying to play bi-partisan politics, we're just trying to test some new features._ + +Showing the date last visited and being able to sort contacts by the date they were last visited by a CHW are the first two features designed to achieve Universal Health Coverage (UHC). While the world is quickly catching onto the importance of this, we know that not all programs are ready to implement this approach. Feature #4525 makes it possible to turn these UHC features on or off. It's still very early in our UHC design process so we'll be closely monitoring these features and conduct feedback sessions, so the UHC features previously described may still undergo some iteration. Check on the status of these features before implementing them in your project. + +[As was described earlier](#view-date-last-visited-for-places-on-the-people-tab), enabling UHC mode is as simple as giving a user the permission `can_view_last_visited_date`. This will give the user the last visit date in the people list and the ability to sort by the last visit date. Make sure you add the needed field to the forms you want to include as part of the last visit date calculation to avoid having a long list of "Last visit unknown". Once CHWs start submitting these forms, the dates on the list will slowly update. + +{{< figure src="../images/2_16_0-4525.png" link="../images/2_16_0-4525.png" caption="Comparison" >}} + +[[#4525](https://github.com/medic/cht-core/issues/4525)] + +### Expand use of the verify button for manager review of CHW reports + +_The exciting world of data cleaning just got better._ + +We've created a new and improved verification workflow for managers. Before, we just had two states for each report, verified and unverified. A report was verified by clicking the verify button. + +{{< figure src="../images/2_16_0-4529-1.png" link="../images/2_16_0-4529-1.png" caption="Comparison" >}} + +With the new feature, clicking on the verify button opens a small menu with two options: Correct and Has errors. This allows a manager to review a report and mark it correct if it looks good and mark it as having errors if they need to follow up with the CHW for further verification. The status will also be synced to the CHW's phone so they can see which reports were marked correct by their manager and which were marked as having errors. + +[With our new configurable roles](#ability-to-add-more-user-roles), it is also possible for managers to have the ability to review reports while preventing CHWs from having this option, even if both are restricted/offline-first users. + +This feature was built to support the mRDT error-checking workflow for the Muso Innovation Network. Supervisors must log in to view photos of the mRDTs ([built in 2.14.0](https://docs.google.com/document/d/1uXSqntenhxlGOeFtP7ScLcFmoid3kagPYn-EDoodP3s/edit#heading=h.4bwl8oo2mtpi)) and check that the diagnosis reported by the CHW matches the photos. If the supervisor sees an error, they can now use this feature to mark it as such. Error rates are part of the CHW's performance metrics so supervisors can see which CHWs are in need of additional training on implementing mRDTs. To complement this workflow, we built a widget on the CHP's Targets page to accompany this workflow that tracks their monthly error rate. + +{{< figure src="../images/2_16_0-4529-2.png" link="../images/2_16_0-4529-2.png" caption="Comparison" >}} + +[[#4529](https://github.com/medic/cht-core/issues/4529)] + +### Allow supervisors to review specific patient reports + +_We call this feature Super-Vision! Supervisors now have the magical ability to see reports about patients without being able to view the patients themselves. #superpowers-for-supervisors_ + +Apart from Standard, where we have very small numbers of users, supervisors are not able to view all patient reports due to device storage limits and app performance issues. However, there may be times when there are specific reports about patients that supervisors need to see, review, or take action on. This feature is not meant to allow supervisors to view all patient reports about every patient and it does not give supervisors the ability to see patient profiles. It is meant to better support workflows like reviewing mRDT images or confirming death reports. Currently, if a supervisor wanted to review an mRDT image in a patient assessment form or get a death confirmation task, she would need to have access to the patient. With this new feature, the supervisor only needs access to the patient assessment form or the death report form in order to do the review or receive the task. + +Below you'll see the Reports page from the supervisor's view. In this example, the supervisor has access to families and family reports, but does not have access to patients. Using this feature, we've configured it so that the supervisor **does** have access to patient assessment forms so that they can be reviewed, even though she doesn't have access to the patients themselves. As you can see in the screenshots below, the CHW has access to all patient- and family-level reports while the supervisor has access to all family-level reports AND the patient assessment report, but no other patient-level reports. + +{{< figure src="../images/2_16_0-4591-1.png" link="../images/2_16_0-4591-1.png" caption="Comparison" >}} + +If you want a report submitted by the CHW about a patient to be viewable by the supervisor, you'll need to make sure that the supervisor has access to families (`replication_depth` of 2 in most cases) but no access to patients. You will also need to add a field to the patient-level form that the supervisor needs access to. The field should be a `hidden` field called `needs_signoff` that must be set to true in cases where the report needs to be reviewed by a manager. For example, if you only wanted a manager to review patient assessments where an mRDT was conducted, come up with a conditional statement to set the variable to true only for assessments where the mRDT was done. This hidden field must be a top-level field (not in any group and will be in `doc.fields.needs_signoff` when you submit). To test, upload your form with this field, fill it out and submit. Log in as a user who is the supervisor of the CHW who submitted the form and make sure you are able to see the form you just submitted. + +Example XLSForm: +{{< figure src="../images/2_16_0-4591-2.png" link="../images/2_16_0-4591-2.png" caption="XLSForm" >}} + +[[#4591](https://github.com/medic/cht-core/issues/4591)] + +### Add new statuses to the status filter on the reports page + +_Because even Superheros could use some help organizing their Inbox._ + +With the [new feature that allows managers to review reports](#expand-use-of-the-verify-button-for-manager-review-of-chw-reports), we've updated the status filter to help managers easily find reports they need to review or reports they marked as having errors that need follow up. With these changes, we have retained the ability to filter by valid and invalid SMS reports. Here's what happens when you select each of these filter options: + +* **Manager review - "Not reviewed":** displays all valid reports (SMS and app) that have not been marked as correct or having errors by a manager +* **Manager review - "Reviewed: errors":** displays all reports (app or SMS) that were marked as having errors by a manager +* **Manager review - "Reviewed: correct":** displays all reports (app or SMS) that were marked as correct by a manager +* **SMS validity - "Valid SMS":** displays all SMS reports that were valid when received (regardless of whether they are "Not reviewed", "Reviewed: errors", or "Reviewed: correct") +* **SMS validity - "Invalid SMS":** displays all SMS reports that were invalid when received and have red dots (applied automatically) + +For example, if a manager wanted to review any recent patient assessments that they might have access to, she would filter by the patient assessment form type and the "Manager review - Not reviewed" status filter. This would give a list of assessment forms that have not yet been reviewed. + + +{{< figure src="../images/2_16_0-4577-1.png" link="../images/2_16_0-4577-1.png" caption="Comparison" >}} + +#### Before +{{< figure src="../images/2_16_0-4577-2.png" link="../images/2_16_0-4577-2.png" caption="Screenshot" >}} + +#### After +{{< figure src="../images/2_16_0-4577-3.png" link="../images/2_16_0-4577-3.png" caption="Screenshot" >}} + + +[[#4577](https://github.com/medic/cht-core/issues/4577)] + +### Use family equity score in tasks and actions about family members + +_Jokes aside, this features is an important step in being able to deliver a preferential option for the poor. Read more about this here: [https://www.pih.org/article/in-the-company-of-the-poor](https://www.pih.org/article/in-the-company-of-the-poor)_ + +Last year, we began implementing an equity survey in Kenya that determines a household's wealth quintile based on a number of questions about their home, possessions, and access to safe drinking water, among other things. Although the wealth quintile could be used to generate tasks for the household, we wanted to make the equity quintile useful in targeting interventions at the patient level. With this feature, we're now able to use the equity score to generate specific tasks about patients, such as increasing the number of pregnancy follow-ups for women in poorer households. We're also able to display specific notes or questions within forms for patients in lower wealth quintiles, such as asking additional questions about children in poorer households when they are being screened for malnutrition. This feature makes the equity score more usable in patient workflows and is the first step toward greater targeting of services. + +We're still learning how to deliver this feature well. We've heard from CHWs that they resist the approach that some families in their community would be "labeled" as poor in the app, even if they acknowledge that they prioritize these families differently in their daily workflows. Though this feature allows that "labeling" to happen on the backend, it may be helpful and important for a CHW to know why a family or patient has been asked these additional questions or given more frequent home visits. The Impact and Design teams are currently getting feedback on appropriate options. Consult your designer and share back what you're thinking and trying so we can all learn together! + +The feature works by pulling specific fields from a form filled at the family level and copying them to the profile of each family member in the household. For now, we are limited to the national quintile and the urban quintile. We don't pull the raw scores, just the quintiles, which are easier to use in tasks and forms. To make sure your quintiles get copied, simply make sure that you have fields called `NationalQuintile` and `UrbanQuintile` defined as top-level fields in the form you're using at the household level. These must end up at `doc.fields.NationalQuintile` and `doc.fields.UrbanQuintile` for this feature to work correctly. + +#### Sample XLSForm +{{< figure src="../images/2_16_0-4700.png" link="../images/2_16_0-4700.png" caption="XLSForm" >}} + +[[#4600](https://github.com/medic/cht-core/issues/4600)] + +### Ability to add more user roles + +_Because CHW Janet, CHW Supervisor Ann, and Paul the Data Guy don't wear the same hat in real life and now they don't have to in the app, either._ + +In order to make it possible to show the UHC mode features for some CHWs and not others, we decided to go ahead and implement configurable user roles. Up until now, we were limited to one user role for users that need offline access to their data. You have probably heard of the "restricted" user - this is the user type that allowed a CHW or manager to access data offline. However, this was limiting because every user that had offline data access had to have the same set of permissions. So, for example, a CHW and a supervisor had to have the same set of permissions, requiring both to have the permission to do something (such as delete reports) or neither would have permission to do it. This led to restrictions in what supervisors could do in order to avoid giving too many permissions to CHWs. + +With 2.16.0, we now have configurable roles! This means that a CHW and a supervisor can both access data offline but can have unique roles so that they can have different permissions. For example, a CHW might not be able to delete data, review reports, or bulk delete, but a supervisor could be given the ability to do one or more of these actions without affecting the permissions of the CHW. + +New roles can be created in the configuration pages. Instead of a permissions page, we now have a roles & permissions page. On this page we have a new tab for creating and managing user roles. Creating a new user role is as simple as creating a name and translation key for the user role and making sure you select the "Offline" checkbox if this user type needs access to data offline. + +{{< figure src="../images/2_16_0-4525-1.png" link="../images/2_16_0-4525-1.png" caption="Screenshot" >}} + +The permissions page has also been updated to better accommodate a greater number of roles. We've changed the layout to a new format. This layout is temporary for now and we expect to improve it later in the year. You can see in this example that we now have roles for Supervisor, CHW and Online User, but you can create as many roles as you need, both for users that need access to data offline and for those accessing the app online. + +{{< figure src="../images/2_16_0-4525-2.png" link="../images/2_16_0-4525-2.png" caption="Screenshot" >}} + +[[#4525](https://github.com/medic/cht-core/issues/4525)] + +### Changed use of colored dot on the reports page + +_Seeing spots? Or do we mean dots? Either way, you're about to see a whole lot less of them. If they don't go away, consult a tech lead or your family eye doctor._ + +Our use of the controversial "green dot" and "red dot" on the reports page hearkens back to the days when 100% of Medic users where using SMS. It was a quick way to see which reports were valid and which were not. Once we started having users on the mobile app, this feature became less useful because every single report was valid. This is because we have more control over how the data is entered and do not rely on the end user entering a valid Medic ID. We decided to modernize our use of red and green dots so that they make more sense across our SMS and app projects. Here's our new approach: + + +* We've removed the green dot completely from valid incoming reports. No dot = all good here = no attention needed. This is regardless of whether it came from the mobile app, a TextForm, or Medic Collect. +* Without green dots on every report, red and green dots now have more meaning. Using our new manager review feature (#4529), a manager can now use a green dot to indicate that a form is correct, and a red dot if it contains an error. +* We also know that it's important to be able to see invalid reports coming in over SMS, either TextForms or Collect forms. For these invalid SMS reports, the red dot with an "x" is automatically applied. You can filter to see all invalid SMS reports by using the status filter dropdown. Here's a summary of how the red and green dots now work: + +{{< figure src="../images/2_16_0-4574-1.png" link="../images/2_16_0-4574-1.png" caption="Comparison" >}} + +Here's a look at the reports list so you can see the before and after: + +{{< figure src="../images/2_16_0-4574-2.png" link="../images/2_16_0-4574-2.png" caption="Comparison" >}} + +The screenshot on the left shows the current use of dots for an SMS project. On a mobile app project, there's a green dot on every report. + +In the screenshot on the right, we've removed the green dots from valid reports. The green dot can be applied when a supervisor has reviewed a report and marked it correct. The red dot for invalid SMS reports is still automatically applied. Additionally, a supervisor can review a report and apply the red dot if the report has errors. + +The supervisor review feature is optional and should only be encouraged if it's part of their workflow. It's also perfectly fine for supervisors to use it selectively - to only mark reports with errors or to only review certain reports (such as mRDT, but not child assessments). The intention isn't to give supervisors more review work but to reduce the noise on the Reports page and make the information that gets shown there more meaningful. + +[[#4574](https://github.com/medic/cht-core/issues/4574)] + +### Updated header for reports + +_UI fairy dust alert! We made viewing reports on mobile prettier._ + +We've updated the header when you're viewing reports in the Reports page. The new design works much better on smaller screens: + +* We've removed the detailed date +* We've moved the relative date to the left side, below the sender name. +* If you hover over the relative date, the full date and exact time the report was received will appear. If you're on a touchscreen, do a long tap on the relative date to see the detailed date. +* If a manager has reviewed this report and marked it correct or marked it as having errors, the green or red dot would appear at the top right. + +{{< figure src="../images/2_16_0-4576-1.png" link="../images/2_16_0-4576-1.png" caption="Comparison" >}} + +#### Before + +{{< figure src="../images/2_16_0-4576-2.png" link="../images/2_16_0-4576-2.png" caption="Screenshot" >}} + +#### After + +{{< figure src="../images/2_16_0-4576-3.png" link="../images/2_16_0-4576-3.png" caption="Screenshot" >}} + +[[#4576](https://github.com/medic/cht-core/issues/4576)] + +### Allow death confirmation form to specify the date of death + +_Because the only thing worse than getting your birthday wrong is…_ + +In 2.15.0, [we added support for death reporting workflows](/releases/2_15_0.md#death-reporting). One glitch we realized was that the date of death was being set to the date that the death confirmation form was submitted. With 2.16.0, we've added an improvement to the workflow. It's now possible to set a specific date of death in your death confirmation form. This makes the workflow more flexible by allowing a nurse to enter the confirmed date of death in the death confirmation form. + +In order to include a user-selected date of death as the official date of death listed in the Medic app, you'll need to make sure there is a field in the death confirmation form that lists the exact date of death and then indicate in your `app_settings` that this field should be used for the date of death. + +Example XLSForm with `date_of_death` field: + +{{< figure src="../images/2_16_0-4636.png" link="../images/2_16_0-4636.png" caption="Screenshot" >}} + +Example `app_settings` configuration: + +```javascript +"transitions": { + "death_reporting": true +}, +"death_reporting": { + "mark_deceased_forms": [ + "death_confirmation" + ], + "undo_deceased_forms": [ + "undo_death" + ], + "date_field": "fields.date_of_death" +} +``` + +[[#4636](https://github.com/medic/cht-core/issues/4636)] + + +## Bug Fixes + + +### Updated google-libphonenumber + +_Now you can change your number to avoid your ex without missing a single Medic reminder._ + +We've updated to the latest google-libphonenumber to make sure our app will accept new phone numbers across all of the countries where we work. The current version is 3.1.8. [[#4665](https://github.com/medic/cht-core/issues/4665)] + + +### Fixed a performance issue with loading contacts + + +_CHWs see a lot of people every day. That's a lot of searching! We've improved search performance by 30% which really adds up._ + +Loading contacts is now done with an `allDocs` request instead of using custom views. This improves performance of searching on the people tab and on the reports tab. It's a workaround for now as we look further into the root cause of the slowness. [[#4666](https://github.com/medic/cht-core/issues/4666)] diff --git a/content/en/releases/3_10_0.md b/content/en/releases/3_10_0.md index df44590631..767ef5ceaa 100644 --- a/content/en/releases/3_10_0.md +++ b/content/en/releases/3_10_0.md @@ -61,7 +61,7 @@ App builders can now configure privacy policies for every language. When a priva {{< figure src="../images/3_10-privacy-policies.png" link="../images/3_10-privacy-policies.png" caption="Privacy policies" >}} -See [the documentation]( {{< relref "building/privacy-policies" >}} ) for more information. +See [the documentation](/building/privacy-policies) for more information. ## More granular replication depth configuration for offline users diff --git a/content/en/releases/3_11_0.md b/content/en/releases/3_11_0.md index 34b3b69842..b5ba7122c9 100644 --- a/content/en/releases/3_11_0.md +++ b/content/en/releases/3_11_0.md @@ -87,7 +87,7 @@ The UI framework has been upgraded from the deprecated AngularJS v1.6 to Angular ### RapidPro SMS gateway -SMS messages can now be sent and received using a RapidPro instance. This allows for integration with a wide range of SMS aggregators for a high scale SMS deployment. Learn more in the [feature documentation]({{< relref "building/messaging/gateways/rapidpro" >}} ). +SMS messages can now be sent and received using a RapidPro instance. This allows for integration with a wide range of SMS aggregators for a high scale SMS deployment. Learn more in the [feature documentation](/building/messaging/gateways/rapidpro). - [cht-core#6532](https://github.com/medic/cht-core/issues/6532): Add RapidPro as an SMS Gateway diff --git a/content/en/releases/3_14_0.md b/content/en/releases/3_14_0.md index 770d9758d6..85c0471279 100644 --- a/content/en/releases/3_14_0.md +++ b/content/en/releases/3_14_0.md @@ -58,7 +58,7 @@ Old Dates | New Dates :-------------------------:|:-------------------------: {{< figure src="../images/3_14_0-7294-old.png" link="../images/3_14_0-7294-old.png" >}} | {{< figure src="../images/3_14_0-7294-new.png" link="../images/3_14_0-7294-new.png" >}} -Additionally, a new [`to-bikram-sambat` xPath function]({{< ref "building/forms/app#to-bikram-sambat" >}}) has been added that converts a `date` to a `string` containing the value of the date in the Bikram Sambat format. +Additionally, a new [`to-bikram-sambat` xPath function](/building/forms/app#to-bikram-sambat) has been added that converts a `date` to a `string` containing the value of the date in the Bikram Sambat format. [#7294](https://github.com/medic/cht-core/issues/7294): Use Bikram Sambat dates throughout the webapp when Nepali locale selected @@ -75,9 +75,9 @@ We have updated the tab labels to always display even on small screens. Addition ### Improved server-side purging -We have made several improvements to our [server-side purging]({{< ref "technical-overview/data/performance/purging#server-side" >}}) functionality allowing it to perform better at scale. +We have made several improvements to our [server-side purging](/technical-overview/data/performance/purging#server-side) functionality allowing it to perform better at scale. -- Enhanced logging during purging via a new [`purgelog` document]({{< ref "technical-overview/data/performance/purging#purged-documents-server-side" >}}) saved in the `medic-sentinel` database after every purge. +- Enhanced logging during purging via a new [`purgelog` document](/technical-overview/data/performance/purging#purged-documents-server-side) saved in the `medic-sentinel` database after every purge. - If a contact has more than 20,000 records, it will be skipped and none of its records will be purged. - A log will appear for the skipped contact and the id of this contact will be saved in a new `skipped_contacts` property in the `purgelog`. - The batch size for contacts to purge will dynamically adjust based on the number of records associated with the contacts. diff --git a/content/en/releases/3_17_0.md b/content/en/releases/3_17_0.md index c50c7a3d63..d1d6836337 100644 --- a/content/en/releases/3_17_0.md +++ b/content/en/releases/3_17_0.md @@ -46,13 +46,13 @@ NOTE: The old version of the UI can be temporarily re-enabled by following the i ### Places created with bulk upload now have a primary contact -We have improved the [bulk upload]({{< ref "building/training/users-bulk-load" >}}) feature to automatically assign a primary contact to a newly created place. +We have improved the [bulk upload](/building/training/users-bulk-load) feature to automatically assign a primary contact to a newly created place. - [#7724](https://github.com/medic/cht-core/issues/7724): Places created with bulk upload don't have a primary contact. ### Privacy policy is now public -Android app submission now requires a URL to the apps' privacy policy. To facilitate this process we have made the [privacy policy]({{< ref "building/privacy-policies" >}}) public in the login page. +Android app submission now requires a URL to the apps' privacy policy. To facilitate this process we have made the [privacy policy](/building/privacy-policies) public in the login page. {{< figure src="../images/3_17_0-7662-privacy-policy.png" link="../images/3_17_0-7662-privacy-policy.png" >}} diff --git a/content/en/releases/3_4_0.md b/content/en/releases/3_4_0.md index c952abc459..2617598272 100644 --- a/content/en/releases/3_4_0.md +++ b/content/en/releases/3_4_0.md @@ -47,7 +47,7 @@ This change removes the continuous replication in favor of making a short lived ## Customizable branding -You can now configure the webapp logo, title, and favicon to use your project's branding [medic#4849](https://github.com/medic/cht-core/issues/4849). You can also add logos of your partners to show on the About page [medic#4850](https://github.com/medic/cht-core/issues/4850). More information is available in the [feature overview]( {{< relref "building/branding/application-graphics" >}} ) and the [configuration documentation](https://docs.communityhealthtoolkit.org/apps/reference/resources/). +You can now configure the webapp logo, title, and favicon to use your project's branding [medic#4849](https://github.com/medic/cht-core/issues/4849). You can also add logos of your partners to show on the About page [medic#4850](https://github.com/medic/cht-core/issues/4850). More information is available in the [feature overview](/building/branding/application-graphics) and the [configuration documentation](https://docs.communityhealthtoolkit.org/apps/reference/resources/). ## Improved performance loading Contacts tab diff --git a/content/en/releases/4_0_0.md b/content/en/releases/4_0_0.md index 6684eb33eb..fc7fb6da15 100644 --- a/content/en/releases/4_0_0.md +++ b/content/en/releases/4_0_0.md @@ -18,10 +18,10 @@ Check the repository for the [latest known issues](https://github.com/medic/cht- ### Breaking changes -To prepare for this release, read through our [Preparing to Upgrade documentation]({{< ref "hosting/cht/migration/preparing-for-4" >}}). +To prepare for this release, read through our [Preparing to Upgrade documentation](/hosting/cht/migration/preparing-for-4). {{< callout type="warning" >}} - Be aware that as this is a major upgrade some manual steps are required - following the usual upgrade process will not work. [Data migration documentation is coming soon]({{< ref "/hosting/cht" >}}), but in the meantime reach out on [the forum](https://forum.communityhealthtoolkit.org/) for direct support in upgrading. New projects should start on 4.0.0 to make the following upgrades easier. + Be aware that as this is a major upgrade some manual steps are required - following the usual upgrade process will not work. [Data migration documentation is coming soon](//hosting/cht), but in the meantime reach out on [the forum](https://forum.communityhealthtoolkit.org/) for direct support in upgrading. New projects should start on 4.0.0 to make the following upgrades easier. {{< /callout >}} #### New architecture @@ -53,7 +53,7 @@ The software the CHT uses to render forms has been updated with more features, b #### Secure credentials migration -Credentials used for external integration via SIH or Outbound Push features are now stored in a different way which requires a manual upgrade step. Read about how to store credentials in 4.0.0 in the [API documentation]({{< ref "building/reference/api#credentials" >}}). +Credentials used for external integration via SIH or Outbound Push features are now stored in a different way which requires a manual upgrade step. Read about how to store credentials in 4.0.0 in the [API documentation](/building/reference/api#credentials). - [#5904](https://github.com/medic/cht-core/issues/5904): Cluster safe credentials diff --git a/content/en/releases/4_17_0.md b/content/en/releases/4_17_0.md index c31790ff2d..8c441d8784 100644 --- a/content/en/releases/4_17_0.md +++ b/content/en/releases/4_17_0.md @@ -24,20 +24,20 @@ None. The login experience now includes a **password reset page** for users who are required to change their password upon first login. This page ensures that new users and users whose passwords have been manually updated by an admin are prompted to update their credentials before accessing the app. -See the [workflow documentation]( {{< ref "building/login#password-reset-on-first-login" >}} ) for more details. +See the [workflow documentation]( {{< ref "building/login#password-reset-on-first-login" >}}) for more details. ## Highlights ### Change password on first login -System admin users create accounts for CHWs and then share the password with them. To enhance the security of these accounts, the CHT now [supports a feature]( {{< ref "building/login#password-reset-on-first-login" >}} ) that prompts users to change their password upon their first login. +System admin users create accounts for CHWs and then share the password with them. To enhance the security of these accounts, the CHT now [supports a feature]( {{< ref "building/login#password-reset-on-first-login" >}}) that prompts users to change their password upon their first login. {{< figure src="/building/login/password-change.png" link="/building/login/password-change.png" class="col-12 col-lg-12" >}} #### Details - By default, new users and users whose passwords have been manually reset by an admin must change their password on their next login. -- This requirement can be bypassed for specific user roles using the [`can_skip_password_change` permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}} ). +- This requirement can be bypassed for specific user roles using the [`can_skip_password_change` permission]( {{< ref "building/reference/app-settings/user-permissions#system-defined-permissions" >}}). - If the permission is **enabled** for a user, they will **not** be required to change their password. - If the permission is **not enabled**, the user **must** change their password before accessing the app. - Subsequent logins won’t require a password change unless the admin manually updates the user’s password. In this case, the user will be prompted to change their password on their next login. diff --git a/content/en/releases/4_18_0.md b/content/en/releases/4_18_0.md index 17cef09919..883143e95b 100644 --- a/content/en/releases/4_18_0.md +++ b/content/en/releases/4_18_0.md @@ -31,9 +31,9 @@ None. {{< figure link="../images/4_18_0-rtl.png" src="../images/4_18_0-rtl.png" >}} -Support for Arabic as a CHT language was [added in `4.16.0`]({{< ref "releases/4_16_0.md#arabic-as-cht-language" >}}). Now, the CHT can properly display content in a full RTL layout! This greatly improves the usability of the application for native RTL language speakers. +Support for Arabic as a CHT language was [added in `4.16.0`](/releases/4_16_0.md#arabic-as-cht-language). Now, the CHT can properly display content in a full RTL layout! This greatly improves the usability of the application for native RTL language speakers. -See [the documentation]( {{< ref "building/translations/localizing#2-rtl-support" >}} ) for more details. +See [the documentation]( {{< ref "building/translations/localizing#2-rtl-support" >}}) for more details. [#9682](https://github.com/medic/cht-core/issues/9682): Add support for Right to Left languages @@ -60,11 +60,11 @@ chw_area --- chw & family_a & family_b -Controlling the data accessible to ["offline" CHT users]({{< ref "building/users#offline-users" >}}) is essential. Often, the [`replication_depth` configuration]({{< ref "technical-overview/data/performance/replication#depth" >}}) is used to limit how much of the contact hierarchy is visible to a user (and downloaded to their device) by preventing the replication of contacts/reports beyond a specified depth. +Controlling the data accessible to ["offline" CHT users](/building/users#offline-users) is essential. Often, the [`replication_depth` configuration](/technical-overview/data/performance/replication#depth) is used to limit how much of the contact hierarchy is visible to a user (and downloaded to their device) by preventing the replication of contacts/reports beyond a specified depth. However, in some cases this configuration is not sufficient. For example, perhaps a CHW Supervisor needs to have access to the contact data for the CHWs they supervise (including the reports for those contacts), but should not have access to all the households/patients served by those CHWs. A typical hierarchy (as seen here) might have the CHW contact and the family household contacts both at the same depth level as children of the CHW Area. If the supervisor user is configured to have a replication depth of `1`, they will not have access to the CHW contact. If the replication depth is set to `2`, the supervisor will have access to all the household contacts. -In this case, the new [`replicate_primary_contacts` configuration]({{< ref "technical-overview/data/performance/replication#replicate-primary-contacts" >}}) can be used to ensure the primary contacts of the places at the user's deepest replication depth are also replicated (even if those contacts are technically located deeper in the hierarchy than the configured depth limit). So, with a replication depth of `1` and `replicate_primary_contacts` set to `true`, the supervisor user will have access to the CHW contact, but not the household contacts. +In this case, the new [`replicate_primary_contacts` configuration](/technical-overview/data/performance/replication#replicate-primary-contacts) can be used to ensure the primary contacts of the places at the user's deepest replication depth are also replicated (even if those contacts are technically located deeper in the hierarchy than the configured depth limit). So, with a replication depth of `1` and `replicate_primary_contacts` set to `true`, the supervisor user will have access to the CHW contact, but not the household contacts. [#8034](https://github.com/medic/cht-core/issues/8034): Add config to allow replicating primary contacts for places at max depth @@ -72,10 +72,10 @@ In this case, the new [`replicate_primary_contacts` configuration]({{< ref "tech New REST endpoints have been added to the CHT API server for retrieving data about contacts and reports. The endpoints support getting the all the data for an identified contact/report. Additionally, an endpoint has been added for getting an array of contact identifiers filtered by contact type and/or a freetext search time. There is also a new endpoint for getting report identifiers filtered by a freetext search term. See the API documentation for more details: -- [`/api/v1/contact/{{uuid}}`]({{< ref "building/reference/api#getapiv1contactuuid" >}}) -- [`/api/v1/contact/uuid`]({{< ref "building/reference/api#get-apiv1contactuuid" >}}) -- [`/api/v1/report/{{uuid}}`]({{< ref "building/reference/api#getapiv1reportuuid" >}}) -- [`/api/v1/report/uuid`]({{< ref "building/reference/api#get-apiv1reportuuid" >}}) +- [`/api/v1/contact/{{uuid}}`](/building/reference/api#getapiv1contactuuid) +- [`/api/v1/contact/uuid`](/building/reference/api#get-apiv1contactuuid) +- [`/api/v1/report/{{uuid}}`](/building/reference/api#getapiv1reportuuid) +- [`/api/v1/report/uuid`](/building/reference/api#get-apiv1reportuuid) [#9586](https://github.com/medic/cht-core/issues/9586): Implement freetext search in cht-datasource diff --git a/content/en/releases/4_19_0.md b/content/en/releases/4_19_0.md index eacc65b6e2..ef4fb3167c 100644 --- a/content/en/releases/4_19_0.md +++ b/content/en/releases/4_19_0.md @@ -34,7 +34,7 @@ None. Contacts are created/modified via highly configurable [contact forms](/building/forms/contact). One major challenge when collecting contact data is ensuring users do not inadvertently enter duplicate records for the same contact. The CHT now supports automatically detecting when a contact being created or edited by a user matches an existing contact record. If a duplicate contact is detected, the user will be given the option of proceeding to the profile of the existing contact. Alternatively, the user can choose to override the duplicate detection logic and continue creating/editing the contact as originally intended. -See [the documentation]( {{< ref "/building/contact-management/contacts/#duplicate-contact-detection" >}} ) for more details. +See [the documentation]( {{< ref "/building/contact-management/contacts/#duplicate-contact-detection" >}}) for more details. ### Add user-agent header to outgoing requests diff --git a/content/en/releases/4_1_0.md b/content/en/releases/4_1_0.md index 5f1f3338c6..98f1f71994 100644 --- a/content/en/releases/4_1_0.md +++ b/content/en/releases/4_1_0.md @@ -24,7 +24,7 @@ None. #### Bulk delete of reports redesign -The bulk delete of Reports tab has been redesigned to allow the user to select multiple reports and delete them. You can read more about it in the [Reports tab docs]({{< ref "building/reports/#bulk-delete-reports" >}}). +The bulk delete of Reports tab has been redesigned to allow the user to select multiple reports and delete them. You can read more about it in the [Reports tab docs](/building/reports/#bulk-delete-reports). {{< figure src="../images/4_1_0-7778-reports-bulk-mobile.png" class="left col-3 col-lg-3" >}} @@ -36,7 +36,7 @@ The bulk delete of Reports tab has been redesigned to allow the user to select m ### Support replacing a CHW user without any connectivity -Offline users can now be replaced on a device so that a new user can use that device without needing to immediately sync with the server. You can read more about it in [the transitions configuration docs]({{< ref "building/reference/app-settings/transitions#create_user_for_contacts" >}}). +Offline users can now be replaced on a device so that a new user can use that device without needing to immediately sync with the server. You can read more about it in [the transitions configuration docs](/building/reference/app-settings/transitions#create_user_for_contacts). ## And more... diff --git a/content/en/releases/4_20_0.md b/content/en/releases/4_20_0.md index 9909dd3be5..907b56ea21 100644 --- a/content/en/releases/4_20_0.md +++ b/content/en/releases/4_20_0.md @@ -30,7 +30,7 @@ None. {{< figure src="/building/navigation/storage_pressure_screenshot.svg" link="/building/navigation/storage_pressure_screenshot.svg" >}} -The performance and functionality of the CHT app on an offline user's device can be significantly affected when there is not sufficient free disk space. The [storage pressure indicator]({{< ref "building/navigation/#storage-pressure-indicator" >}}) in the menu drawer shows users, at a glance, how much free disk space they have left. +The performance and functionality of the CHT app on an offline user's device can be significantly affected when there is not sufficient free disk space. The [storage pressure indicator](/building/navigation/#storage-pressure-indicator) in the menu drawer shows users, at a glance, how much free disk space they have left. [#9872](https://github.com/medic/cht-core/issues/9872): Provide offline user device storage info at a glance @@ -42,7 +42,7 @@ Single Sign-On (SSO) enables users connecting to a CHT instance to authenticate SSO authentication is implemented with the industry standard [OpenID Connect](https://openid.net/) (OIDC) protocol. Any OIDC-compliant authentication server can be integrated with the CHT. -See [the documentation]({{< ref "/hosting/sso" >}}) for more details on configuration and functionality. +See [the documentation](//hosting/sso) for more details on configuration and functionality. [#9735](https://github.com/medic/cht-core/issues/9735): Single sign on (SSO) using identity provider diff --git a/content/en/releases/4_21_0.md b/content/en/releases/4_21_0.md index 06e0c203d5..a83a906187 100644 --- a/content/en/releases/4_21_0.md +++ b/content/en/releases/4_21_0.md @@ -38,7 +38,7 @@ with tasks being sorted by their due date. {{< card link="/building/tasks/tasks-overview/tasks-prioritization.png" image="/building/tasks/tasks-overview/tasks-prioritization.png" method="resize">}} {{< /cards >}} -See [the documentation]({{< ref "/building/tasks/tasks-overview/#task-prioritization" >}}) for more details on configuration and functionality. +See [the documentation](//building/tasks/tasks-overview/#task-prioritization) for more details on configuration and functionality. ### Accessing the logged-in user's contact summary in app forms and app forms permissions @@ -48,13 +48,13 @@ the logged-in user's contact summary is now available in app forms and app forms This allows hiding/displaying forms depending on the current user's context and allows data about the logged-in user to be used in form calculations. -See [the form inputs documentation]({{< ref "building/forms/configuring/form-inputs/#user-contact-summary-data" >}}) and [the form properties documentation]({{< ref "building/forms/app/#formsappform_namepropertiesjson" >}}) for more details on configuration and functionality. +See [the form inputs documentation](/building/forms/configuring/form-inputs/#user-contact-summary-data) and [the form properties documentation](/building/forms/app/#formsappform_namepropertiesjson) for more details on configuration and functionality. ### Support opening contact edit form from task Task actions with `type: 'contact'` can now be configured to redirect the user to the contact form to edit a contact, while this feature previously only allowed redirecting to a contact form to create a contact. -See [the documentation]({{< ref "building/tasks/managing-tasks/launch-contact-form" >}}) for more details on configuration and functionality. +See [the documentation](/building/tasks/managing-tasks/launch-contact-form) for more details on configuration and functionality. ## And more... diff --git a/content/en/releases/_index.md b/content/en/releases/_index.md index bbb55d14c6..55af044299 100644 --- a/content/en/releases/_index.md +++ b/content/en/releases/_index.md @@ -87,142 +87,142 @@ Devices with more navigation systems are more likely to get a more accurate loca ## Release Notes ### 4.x -- [4.21.1]({{% relref "releases/4_21_1.md" %}}) - 2025-07-30 -- [4.21.0]({{% relref "releases/4_21_0.md" %}}) - 2025-06-25 -- [4.20.1]({{% relref "releases/4_20_1.md" %}}) - 2025-07-30 -- [4.20.0]({{% relref "releases/4_20_0.md" %}}) - 2025-06-04 -- [4.19.0]({{% relref "releases/4_19_0.md" %}}) - 2025-05-13 -- [4.18.0]({{% relref "releases/4_18_0.md" %}}) - 2025-03-21 -- [4.17.0]({{% relref "releases/4_17_0.md" %}}) - 2025-02-05 -- [4.16.0]({{% relref "releases/4_16_0.md" %}}) - 2025-01-16 -- [4.15.0]({{% relref "releases/4_15_0.md" %}}) - 2024-11-19 -- [4.14.0]({{% relref "releases/4_14_0.md" %}}) - 2024-11-06 -- [4.13.0]({{% relref "releases/4_13_0.md" %}}) - 2024-10-22 -- [4.12.0]({{% relref "releases/4_12_0.md" %}}) - 2024-10-02 -- [4.11.0]({{% relref "releases/4_11_0.md" %}}) - 2024-09-26 -- [4.10.0]({{% relref "releases/4_10_0.md" %}}) - 2024-08-15 -- [4.9.0]({{% relref "releases/4_9_0.md" %}}) - 2024-06-26 -- [4.8.1]({{% relref "releases/4_8_1.md" %}}) - 2024-06-20 -- [4.8.0]({{% relref "releases/4_8_0.md" %}}) - 2024-05-23 -- [4.7.2]({{% relref "releases/4_7_2.md" %}}) - 2024-06-19 -- [4.7.1]({{% relref "releases/4_7_1.md" %}}) - 2024-05-15 -- [4.7.0]({{% relref "releases/4_7_0.md" %}}) - 2024-05-07 -- [4.6.0]({{% relref "releases/4_6_0.md" %}}) - 2024-03-22 -- [4.5.2]({{% relref "releases/4_5_2.md" %}}) - 2024-02-09 -- [4.5.1]({{% relref "releases/4_5_1.md" %}}) - 2023-12-12 -- [4.5.0]({{% relref "releases/4_5_0.md" %}}) - 2023-11-19 -- [4.4.2]({{% relref "releases/4_4_2.md" %}}) - 2023-12-12 -- [4.4.1]({{% relref "releases/4_4_1.md" %}}) - 2023-10-10 -- [4.4.0]({{% relref "releases/4_4_0.md" %}}) - 2023-09-21 -- [4.3.2]({{% relref "releases/4_3_2.md" %}}) - 2023-10-10 -- [4.3.1]({{% relref "releases/4_3_1.md" %}}) - 2023-08-30 -- [4.3.0]({{% relref "releases/4_3_0.md" %}}) - 2023-08-18 -- [4.2.4]({{% relref "releases/4_2_4.md" %}}) - 2023-10-10 -- [4.2.3]({{% relref "releases/4_2_3.md" %}}) - 2023-09-25 -- [4.2.2]({{% relref "releases/4_2_2.md" %}}) - 2023-07-07 -- [4.2.1]({{% relref "releases/4_2_1.md" %}}) - 2023-06-10 -- [4.2.0]({{% relref "releases/4_2_0.md" %}}) - 2023-05-25 -- [4.1.2]({{% relref "releases/4_1_2.md" %}}) - 2023-06-19 -- [4.1.1]({{% relref "releases/4_1_1.md" %}}) - 2023-03-21 -- [4.1.0]({{% relref "releases/4_1_0.md" %}}) - 2022-12-12 -- [4.0.1]({{% relref "releases/4_0_1.md" %}}) - 2022-12-01 -- [4.0.0]({{% relref "releases/4_0_0.md" %}}) - 2022-11-08 +- [4.21.1](/releases/4_21_1.md) - 2025-07-30 +- [4.21.0](/releases/4_21_0.md) - 2025-06-25 +- [4.20.1](/releases/4_20_1.md) - 2025-07-30 +- [4.20.0](/releases/4_20_0.md) - 2025-06-04 +- [4.19.0](/releases/4_19_0.md) - 2025-05-13 +- [4.18.0](/releases/4_18_0.md) - 2025-03-21 +- [4.17.0](/releases/4_17_0.md) - 2025-02-05 +- [4.16.0](/releases/4_16_0.md) - 2025-01-16 +- [4.15.0](/releases/4_15_0.md) - 2024-11-19 +- [4.14.0](/releases/4_14_0.md) - 2024-11-06 +- [4.13.0](/releases/4_13_0.md) - 2024-10-22 +- [4.12.0](/releases/4_12_0.md) - 2024-10-02 +- [4.11.0](/releases/4_11_0.md) - 2024-09-26 +- [4.10.0](/releases/4_10_0.md) - 2024-08-15 +- [4.9.0](/releases/4_9_0.md) - 2024-06-26 +- [4.8.1](/releases/4_8_1.md) - 2024-06-20 +- [4.8.0](/releases/4_8_0.md) - 2024-05-23 +- [4.7.2](/releases/4_7_2.md) - 2024-06-19 +- [4.7.1](/releases/4_7_1.md) - 2024-05-15 +- [4.7.0](/releases/4_7_0.md) - 2024-05-07 +- [4.6.0](/releases/4_6_0.md) - 2024-03-22 +- [4.5.2](/releases/4_5_2.md) - 2024-02-09 +- [4.5.1](/releases/4_5_1.md) - 2023-12-12 +- [4.5.0](/releases/4_5_0.md) - 2023-11-19 +- [4.4.2](/releases/4_4_2.md) - 2023-12-12 +- [4.4.1](/releases/4_4_1.md) - 2023-10-10 +- [4.4.0](/releases/4_4_0.md) - 2023-09-21 +- [4.3.2](/releases/4_3_2.md) - 2023-10-10 +- [4.3.1](/releases/4_3_1.md) - 2023-08-30 +- [4.3.0](/releases/4_3_0.md) - 2023-08-18 +- [4.2.4](/releases/4_2_4.md) - 2023-10-10 +- [4.2.3](/releases/4_2_3.md) - 2023-09-25 +- [4.2.2](/releases/4_2_2.md) - 2023-07-07 +- [4.2.1](/releases/4_2_1.md) - 2023-06-10 +- [4.2.0](/releases/4_2_0.md) - 2023-05-25 +- [4.1.2](/releases/4_1_2.md) - 2023-06-19 +- [4.1.1](/releases/4_1_1.md) - 2023-03-21 +- [4.1.0](/releases/4_1_0.md) - 2022-12-12 +- [4.0.1](/releases/4_0_1.md) - 2022-12-01 +- [4.0.0](/releases/4_0_0.md) - 2022-11-08 ### 3.x -- [3.17.2]({{% relref "releases/3_17_2.md" %}}) - 2023-10-10 -- [3.17.1]({{% relref "releases/3_17_1.md" %}}) - 2022-12-02 -- [3.17.0]({{% relref "releases/3_17_0.md" %}}) - 2022-10-11 -- [3.16.1]({{% relref "releases/3_16_1.md" %}}) - 2022-12-02 -- [3.16.0]({{% relref "releases/3_16_0.md" %}}) - 2022-08-12 -- [3.15.0]({{% relref "releases/3_15_0.md" %}}) - 2022-05-03 -- [3.14.2]({{% relref "releases/3_14_2.md" %}}) - 2022-03-17 -- [3.14.1]({{% relref "releases/3_14_1.md" %}}) - 2022-03-08 -- [3.14.0]({{% relref "releases/3_14_0.md" %}}) - 2022-02-11 -- [3.13.0]({{% relref "releases/3_13_0.md" %}}) - 2021-09-28 -- [3.12.1]({{% relref "releases/3_12_1.md" %}}) - 2021-09-02 -- [3.12.0]({{% relref "releases/3_12_0.md" %}}) - 2021-07-28 -- [3.11.3]({{% relref "releases/3_11_3.md" %}}) - 2021-09-02 -- [3.11.2]({{% relref "releases/3_11_2.md" %}}) - 2021-07-21 -- [3.11.1]({{% relref "releases/3_11_1.md" %}}) - 2021-07-12 -- [3.11.0]({{% relref "releases/3_11_0.md" %}}) - 2021-04-20 -- [3.10.5]({{% relref "releases/3_10_5.md" %}}) - 2021-07-21 -- [3.10.4]({{% relref "releases/3_10_4.md" %}}) - 2021-07-12 -- [3.10.3]({{% relref "releases/3_10_3.md" %}}) - 2021-03-17 -- [3.10.2]({{% relref "releases/3_10_2.md" %}}) - 2021-01-25 -- [3.10.1]({{% relref "releases/3_10_1.md" %}}) - 2020-12-08 -- [3.10.0]({{% relref "releases/3_10_0.md" %}}) - 2020-09-08 -- [3.9.2]({{% relref "releases/3_9_2.md" %}}) - 2020-12-06 -- [3.9.1]({{% relref "releases/3_9_1.md" %}}) - 2020-08-20 -- [3.9.0]({{% relref "releases/3_9_0.md" %}}) - 2020-06-19 -- [3.8.2]({{% relref "releases/3_8_2.md" %}}) - 2020-08-20 -- [3.8.1]({{% relref "releases/3_8_1.md" %}}) - 2020-04-06 -- [3.8.0]({{% relref "releases/3_8_0.md" %}}) - 2020-02-10 -- [3.7.1]({{% relref "releases/3_7_1.md" %}}) - 2019-11-12 -- [3.7.0]({{% relref "releases/3_7_0.md" %}}) - 2019-10-22 -- [3.6.2]({{% relref "releases/3_6_2.md" %}}) - 2020-03-24 -- [3.6.1]({{% relref "releases/3_6_1.md" %}}) - 2019-08-06 -- [3.6.0]({{% relref "releases/3_6_0.md" %}}) - 2019-07-17 -- [3.5.0]({{% relref "releases/3_5_0.md" %}}) - 2019-06-28 -- [3.4.1]({{% relref "releases/3_4_1.md" %}}) - 2019-06-04 -- [3.4.0]({{% relref "releases/3_4_0.md" %}}) - 2019-03-27 -- [3.3.0]({{% relref "releases/3_3_0.md" %}}) - 2019-02-22 -- [3.2.1]({{% relref "releases/3_2_1.md" %}}) - 2019-01-22 -- [3.2.0]({{% relref "releases/3_2_0.md" %}}) - 2019-01-22 -- [3.1.0]({{% relref "releases/3_1_0.md" %}}) - 2018-11-21 -- [3.0.0]({{% relref "releases/3_0_0.md" %}}) - 2018-11-14 +- [3.17.2](/releases/3_17_2.md) - 2023-10-10 +- [3.17.1](/releases/3_17_1.md) - 2022-12-02 +- [3.17.0](/releases/3_17_0.md) - 2022-10-11 +- [3.16.1](/releases/3_16_1.md) - 2022-12-02 +- [3.16.0](/releases/3_16_0.md) - 2022-08-12 +- [3.15.0](/releases/3_15_0.md) - 2022-05-03 +- [3.14.2](/releases/3_14_2.md) - 2022-03-17 +- [3.14.1](/releases/3_14_1.md) - 2022-03-08 +- [3.14.0](/releases/3_14_0.md) - 2022-02-11 +- [3.13.0](/releases/3_13_0.md) - 2021-09-28 +- [3.12.1](/releases/3_12_1.md) - 2021-09-02 +- [3.12.0](/releases/3_12_0.md) - 2021-07-28 +- [3.11.3](/releases/3_11_3.md) - 2021-09-02 +- [3.11.2](/releases/3_11_2.md) - 2021-07-21 +- [3.11.1](/releases/3_11_1.md) - 2021-07-12 +- [3.11.0](/releases/3_11_0.md) - 2021-04-20 +- [3.10.5](/releases/3_10_5.md) - 2021-07-21 +- [3.10.4](/releases/3_10_4.md) - 2021-07-12 +- [3.10.3](/releases/3_10_3.md) - 2021-03-17 +- [3.10.2](/releases/3_10_2.md) - 2021-01-25 +- [3.10.1](/releases/3_10_1.md) - 2020-12-08 +- [3.10.0](/releases/3_10_0.md) - 2020-09-08 +- [3.9.2](/releases/3_9_2.md) - 2020-12-06 +- [3.9.1](/releases/3_9_1.md) - 2020-08-20 +- [3.9.0](/releases/3_9_0.md) - 2020-06-19 +- [3.8.2](/releases/3_8_2.md) - 2020-08-20 +- [3.8.1](/releases/3_8_1.md) - 2020-04-06 +- [3.8.0](/releases/3_8_0.md) - 2020-02-10 +- [3.7.1](/releases/3_7_1.md) - 2019-11-12 +- [3.7.0](/releases/3_7_0.md) - 2019-10-22 +- [3.6.2](/releases/3_6_2.md) - 2020-03-24 +- [3.6.1](/releases/3_6_1.md) - 2019-08-06 +- [3.6.0](/releases/3_6_0.md) - 2019-07-17 +- [3.5.0](/releases/3_5_0.md) - 2019-06-28 +- [3.4.1](/releases/3_4_1.md) - 2019-06-04 +- [3.4.0](/releases/3_4_0.md) - 2019-03-27 +- [3.3.0](/releases/3_3_0.md) - 2019-02-22 +- [3.2.1](/releases/3_2_1.md) - 2019-01-22 +- [3.2.0](/releases/3_2_0.md) - 2019-01-22 +- [3.1.0](/releases/3_1_0.md) - 2018-11-21 +- [3.0.0](/releases/3_0_0.md) - 2018-11-14 ### 2.x -- [2.18.1]({{% relref "releases/2_18_1.md" %}}) - 2018-10-30 -- [2.18.0]({{% relref "releases/2_18_0.md" %}}) - 2018-08-29 -- [2.17.0]({{% relref "releases/2_17_0.md" %}}) - 2018-08-12 -- [2.16.1]({{% relref "releases/2_16_1.md" %}}) - 2018-07-24 -- [2.16.0]({{% relref "releases/2_16_0.md" %}}) - 2018-07-04 -- [2.15.0]({{% relref "releases/2_15_0.md" %}}) - 2018-06-13 -- [2.14.3]({{% relref "releases/2_14_3.md" %}}) - 2018-05-21 -- [2.14.2]({{% relref "releases/2_14_2.md" %}}) - 2018-04-24 -- [2.14.1]({{% relref "releases/2_14_1.md" %}}) - 2018-04-16 -- [2.14.0]({{% relref "releases/2_14_0.md" %}}) - 2018-03-15 -- [2.13.7]({{% relref "releases/2_13_7.md" %}}) - 2018-04-19 -- [2.13.6]({{% relref "releases/2_13_6.md" %}}) - 2018-04-16 -- [2.13.5]({{% relref "releases/2_13_5.md" %}}) - 2018-01-23 -- [2.13.4]({{% relref "releases/2_13_4.md" %}}) - 2018-01-23 -- [2.13.3]({{% relref "releases/2_13_3.md" %}}) - 2018-01-22 -- [2.13.2]({{% relref "releases/2_13_2.md" %}}) - 2018-01-19 -- [2.13.1]({{% relref "releases/2_13_1.md" %}}) - 2017-11-20 -- [2.13.0]({{% relref "releases/2_13_0.md" %}}) - 2017-10-01 -- [2.12.5]({{% relref "releases/2_12_5.md" %}}) - 2017-08-18 -- [2.12.4]({{% relref "releases/2_12_4.md" %}}) - 2017-08-10 -- [2.12.3]({{% relref "releases/2_12_3.md" %}}) - 2017-08-08 -- [2.12.2]({{% relref "releases/2_12_2.md" %}}) - 2017-08-01 -- [2.12.1]({{% relref "releases/2_12_1.md" %}}) - 2017-08-01 -- [2.12.0]({{% relref "releases/2_12_0.md" %}}) - 2017-06-27 -- [2.11.3]({{% relref "releases/2_11_3.md" %}}) - 2017-06-08 -- [2.11.2]({{% relref "releases/2_11_2.md" %}}) - 2017-06-06 -- [2.11.1]({{% relref "releases/2_11_1.md" %}}) - 2017-05-10 -- [2.11.0]({{% relref "releases/2_11_0.md" %}}) - 2017-04-12 -- [2.10.3]({{% relref "releases/2_10_3.md" %}}) - 2017-03-31 -- [2.10.2]({{% relref "releases/2_10_2.md" %}}) - 2017-03-24 -- [2.10.1]({{% relref "releases/2_10_1.md" %}}) - 2017-03-24 -- [2.10.0]({{% relref "releases/2_10_0.md" %}}) - 2017-03-10 -- [2.9.1]({{% relref "releases/2_9_1.md" %}}) - 2017-01-27 -- [2.9.0]({{% relref "releases/2_9_0.md" %}}) - 2016-12-08 -- [2.8.5]({{% relref "releases/2_8_5.md" %}}) - 2016-12-15 -- [2.8.4]({{% relref "releases/2_8_4.md" %}}) - 2016-11-29 -- [2.8.3]({{% relref "releases/2_8_3.md" %}}) - 2016-11-20 -- [2.8.2]({{% relref "releases/2_8_2.md" %}}) - 2016-10-17 -- [2.8.1]({{% relref "releases/2_8_1.md" %}}) - 2016-10-09 -- [2.8.0]({{% relref "releases/2_8_0.md" %}}) - 2016-08-31 -- [2.7.3]({{% relref "releases/2_7_3.md" %}}) - 2016-07-18 -- [2.7.2]({{% relref "releases/2_7_2.md" %}}) - 2016-07-11 -- [2.7.1]({{% relref "releases/2_7_1.md" %}}) - 2016-07-06 -- [2.7.0]({{% relref "releases/2_7_0.md" %}}) - 2016-06-27 -- [2.6.3]({{% relref "releases/2_6_3.md" %}}) - 2016-05-22 -- [2.6.2]({{% relref "releases/2_6_2.md" %}}) - 2016-05-06 -- [2.6.1]({{% relref "releases/2_6_1.md" %}}) - 2016-04-21 -- [2.6.0]({{% relref "releases/2_6_0.md" %}}) - 2016-04-13 +- [2.18.1](/releases/2_18_1.md) - 2018-10-30 +- [2.18.0](/releases/2_18_0.md) - 2018-08-29 +- [2.17.0](/releases/2_17_0.md) - 2018-08-12 +- [2.16.1](/releases/2_16_1.md) - 2018-07-24 +- [2.16.0](/releases/2_16_0.md) - 2018-07-04 +- [2.15.0](/releases/2_15_0.md) - 2018-06-13 +- [2.14.3](/releases/2_14_3.md) - 2018-05-21 +- [2.14.2](/releases/2_14_2.md) - 2018-04-24 +- [2.14.1](/releases/2_14_1.md) - 2018-04-16 +- [2.14.0](/releases/2_14_0.md) - 2018-03-15 +- [2.13.7](/releases/2_13_7.md) - 2018-04-19 +- [2.13.6](/releases/2_13_6.md) - 2018-04-16 +- [2.13.5](/releases/2_13_5.md) - 2018-01-23 +- [2.13.4](/releases/2_13_4.md) - 2018-01-23 +- [2.13.3](/releases/2_13_3.md) - 2018-01-22 +- [2.13.2](/releases/2_13_2.md) - 2018-01-19 +- [2.13.1](/releases/2_13_1.md) - 2017-11-20 +- [2.13.0](/releases/2_13_0.md) - 2017-10-01 +- [2.12.5](/releases/2_12_5.md) - 2017-08-18 +- [2.12.4](/releases/2_12_4.md) - 2017-08-10 +- [2.12.3](/releases/2_12_3.md) - 2017-08-08 +- [2.12.2](/releases/2_12_2.md) - 2017-08-01 +- [2.12.1](/releases/2_12_1.md) - 2017-08-01 +- [2.12.0](/releases/2_12_0.md) - 2017-06-27 +- [2.11.3](/releases/2_11_3.md) - 2017-06-08 +- [2.11.2](/releases/2_11_2.md) - 2017-06-06 +- [2.11.1](/releases/2_11_1.md) - 2017-05-10 +- [2.11.0](/releases/2_11_0.md) - 2017-04-12 +- [2.10.3](/releases/2_10_3.md) - 2017-03-31 +- [2.10.2](/releases/2_10_2.md) - 2017-03-24 +- [2.10.1](/releases/2_10_1.md) - 2017-03-24 +- [2.10.0](/releases/2_10_0.md) - 2017-03-10 +- [2.9.1](/releases/2_9_1.md) - 2017-01-27 +- [2.9.0](/releases/2_9_0.md) - 2016-12-08 +- [2.8.5](/releases/2_8_5.md) - 2016-12-15 +- [2.8.4](/releases/2_8_4.md) - 2016-11-29 +- [2.8.3](/releases/2_8_3.md) - 2016-11-20 +- [2.8.2](/releases/2_8_2.md) - 2016-10-17 +- [2.8.1](/releases/2_8_1.md) - 2016-10-09 +- [2.8.0](/releases/2_8_0.md) - 2016-08-31 +- [2.7.3](/releases/2_7_3.md) - 2016-07-18 +- [2.7.2](/releases/2_7_2.md) - 2016-07-11 +- [2.7.1](/releases/2_7_1.md) - 2016-07-06 +- [2.7.0](/releases/2_7_0.md) - 2016-06-27 +- [2.6.3](/releases/2_6_3.md) - 2016-05-22 +- [2.6.2](/releases/2_6_2.md) - 2016-05-06 +- [2.6.1](/releases/2_6_1.md) - 2016-04-21 +- [2.6.0](/releases/2_6_0.md) - 2016-04-13 ### Earlier releases -- [0.4.15 and earlier]({{% relref "releases/earlier" %}}) +- [0.4.15 and earlier](/releases/earlier) diff --git a/content/en/technical-overview/architecture/cht-core.md b/content/en/technical-overview/architecture/cht-core.md index 19443fa169..31e7004939 100644 --- a/content/en/technical-overview/architecture/cht-core.md +++ b/content/en/technical-overview/architecture/cht-core.md @@ -103,7 +103,7 @@ The CHT Web Application is [reactive](https://angular.io/guide/rx-library), resp | Technology | Usage | |------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [PouchDB](https://pouchdb.com) | To implement an [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}) strategy, which means the data is stored on the client and all pages can load immediately regardless of whether the user has a fast connection, slow connection, or no connection at all. The data is stored in PouchDB, which replicates changes back and forth in the background with the server CouchDB. | +| [PouchDB](https://pouchdb.com) | To implement an [Offline-First](/technical-overview/concepts/offline-first) strategy, which means the data is stored on the client and all pages can load immediately regardless of whether the user has a fast connection, slow connection, or no connection at all. The data is stored in PouchDB, which replicates changes back and forth in the background with the server CouchDB. | | [Enketo](https://enketo.org) | To render configured xforms and help with styling and dynamic elements such as show/hide and validation rules. | | | [ngx-bootstrap](https://github.com/valor-software/ngx-bootstrap) | To integrate Bootstrap components in the Angular application. | | [ngx-translate](https://github.com/ngx-translate/core) | To automatically translate the labels from a Angular application. Read more about [how to configure translations](https://docs.communityhealthtoolkit.org/apps/reference/translations/). | diff --git a/content/en/technical-overview/architecture/overview.md b/content/en/technical-overview/architecture/overview.md index 8c7f89accc..e600494aca 100644 --- a/content/en/technical-overview/architecture/overview.md +++ b/content/en/technical-overview/architecture/overview.md @@ -50,13 +50,13 @@ style SMS fill: transparent ## CHT Core Framework -The [CHT Core Framework]({{< ref "technical-overview/architecture/cht-core" >}}) makes it faster to build full-featured, scalable digital health apps by providing a foundation developers can build on. These apps can support most languages, are [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}), and work on basic phones (via SMS), smartphones, tablets, and computers. +The [CHT Core Framework](/technical-overview/architecture/cht-core) makes it faster to build full-featured, scalable digital health apps by providing a foundation developers can build on. These apps can support most languages, are [Offline-First](/technical-overview/concepts/offline-first), and work on basic phones (via SMS), smartphones, tablets, and computers. App developers are able to define health system roles, permissions and reporting hierarchies, and make use of five highly configurable areas of functionality: messaging, task and schedule management, decision support workflows, longitudinal person profiles, and analytics. {{< see-also page="building" >}} -The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers. Visit the Commuity Health Toolkit website to request a [self-guided demo](https://communityhealthtoolkit.org/contact) of an app built with the Core Framework. You can also explore an [overview of the Core Framework]({{< ref "building" >}}) and its key features. +The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers. Visit the Commuity Health Toolkit website to request a [self-guided demo](https://communityhealthtoolkit.org/contact) of an app built with the Core Framework. You can also explore an [overview of the Core Framework](/building) and its key features. Read more about the [architecture of the CHT Core](/technical-overview/architecture/cht-core). diff --git a/content/en/technical-overview/data/_index.md b/content/en/technical-overview/data/_index.md index d998245187..a01096b42b 100644 --- a/content/en/technical-overview/data/_index.md +++ b/content/en/technical-overview/data/_index.md @@ -70,7 +70,7 @@ Stores meta data about the user including when they last connected to the server ## PouchDB -Used to store documents on the client device to allow for [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}) access. Bidirectional replication is done on the "medic" and "medic-user-{username}-meta" databases. The "medic" database is only partially replicated so the user stores only a subset of the entire CouchDB database for performance and security reasons. +Used to store documents on the client device to allow for [Offline-First](/technical-overview/concepts/offline-first) access. Bidirectional replication is done on the "medic" and "medic-user-{username}-meta" databases. The "medic" database is only partially replicated so the user stores only a subset of the entire CouchDB database for performance and security reasons. {{< see-also page="technical-overview/data/performance/replication" >}} diff --git a/content/en/technical-overview/data/analytics/data-flows-for-analytics.md b/content/en/technical-overview/data/analytics/data-flows-for-analytics.md index daa430f3a6..4a51ad3c92 100644 --- a/content/en/technical-overview/data/analytics/data-flows-for-analytics.md +++ b/content/en/technical-overview/data/analytics/data-flows-for-analytics.md @@ -14,7 +14,7 @@ aliases: - /technical-overview/concepts/data-flows-for-analytics/ --- -In this section, we focus on how data flows through the various components of the Community Health Toolkit. The CHT is built to support the delivery of quality community health care at the last mile. The CHT is designed to work in areas with low connectivity, which means it is an [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}) toolkit for care provision. The architectural and technology choices in the stack are mostly guided by this principle, which will be evident in the discussion of the data management pipeline. +In this section, we focus on how data flows through the various components of the Community Health Toolkit. The CHT is built to support the delivery of quality community health care at the last mile. The CHT is designed to work in areas with low connectivity, which means it is an [Offline-First](/technical-overview/concepts/offline-first) toolkit for care provision. The architectural and technology choices in the stack are mostly guided by this principle, which will be evident in the discussion of the data management pipeline. ## Overview @@ -51,7 +51,7 @@ Ultimately all the data ends up in a CouchDB instance deployed in the cloud whet #### 2. Data Transformation -[CHT Sync](/technical-overview/architecture/cht-sync) is used to move data from CouchDB to a relational database, PostgreSQL in this case. The choice of PostgreSQL for analytics dashboard data sources is to allow use of the more familiar SQL querying. It is an open source tool that can be [easily deployed]({{< ref "/hosting/analytics" >}}). When deployed the service uses [CouchDB's changes feed](https://docs.couchdb.org/en/stable/api/database/changes.html) which allows capturing of everything happening in CouchDB in incremental updates. It is run and monitored by the operating system where it is configured to fetch data at a configurable interval. +[CHT Sync](/technical-overview/architecture/cht-sync) is used to move data from CouchDB to a relational database, PostgreSQL in this case. The choice of PostgreSQL for analytics dashboard data sources is to allow use of the more familiar SQL querying. It is an open source tool that can be [easily deployed](//hosting/analytics). When deployed the service uses [CouchDB's changes feed](https://docs.couchdb.org/en/stable/api/database/changes.html) which allows capturing of everything happening in CouchDB in incremental updates. It is run and monitored by the operating system where it is configured to fetch data at a configurable interval. Data copied over to PostgreSQL is first stored as raw json (document) making use of PostgreSQL's jsonb data type to create an exact replica of a CouchDB database. From this, default views are created at deployment of the service and refreshed during every subsequent run. Additional custom materialized views created later are also refreshed at this time. diff --git a/content/en/technical-overview/data/analytics/muting_in_dashboards.md b/content/en/technical-overview/data/analytics/muting_in_dashboards.md index fe722a43a9..9ffba531a4 100644 --- a/content/en/technical-overview/data/analytics/muting_in_dashboards.md +++ b/content/en/technical-overview/data/analytics/muting_in_dashboards.md @@ -10,7 +10,7 @@ aliases: - /building/guides/database/muting_in_dashboards --- -When a contact gets muted, two of [many things]({{< ref "building/reference/app-settings/transitions#muting" >}}) happen: +When a contact gets muted, two of [many things](/building/reference/app-settings/transitions#muting) happen: - The target contact and all of its descendants have a `muted` property set equal to the date they were muted - an entry is added to the contact's `muting_history` in sentinel's info docs diff --git a/content/en/technical-overview/data/analytics/querying_apdex_telemetry.md b/content/en/technical-overview/data/analytics/querying_apdex_telemetry.md index 3e8fa7ae07..4fbc68769b 100644 --- a/content/en/technical-overview/data/analytics/querying_apdex_telemetry.md +++ b/content/en/technical-overview/data/analytics/querying_apdex_telemetry.md @@ -15,7 +15,7 @@ aliases: Added in `4.7.0`, CHT now records the Apdex (Application Performance Index) that is an open standard for measuring performance of software applications. -Since Apdex is part of the [telemetry]({{< ref "technical-overview/data/performance/telemetry" >}}) system, it is possible to view Apdex data directly from CouchDB. However, it is more useful when aggregated across many users, interactions, and/or days. With this in mind, it is typically easier to query the data using SQL from an [analytics database]({{< ref "technical-overview/data/analytics/data-flows-for-analytics" >}}). +Since Apdex is part of the [telemetry](/technical-overview/data/performance/telemetry) system, it is possible to view Apdex data directly from CouchDB. However, it is more useful when aggregated across many users, interactions, and/or days. With this in mind, it is typically easier to query the data using SQL from an [analytics database](/technical-overview/data/analytics/data-flows-for-analytics). An example of an SQL to view the Apdex score: diff --git a/content/en/technical-overview/data/analytics/querying_training_card_telemetry.md b/content/en/technical-overview/data/analytics/querying_training_card_telemetry.md index ec2ba48a66..47b5dfceb6 100644 --- a/content/en/technical-overview/data/analytics/querying_training_card_telemetry.md +++ b/content/en/technical-overview/data/analytics/querying_training_card_telemetry.md @@ -14,9 +14,9 @@ aliases: Introduced in `4.2.0`, CHT has supported deployment of in-app training cards to facilitate remote training. -Since interaction with training cards logs [telemetry data]({{< ref "technical-overview/data/performance/telemetry" >}}), it is possible to view the data directly from CouchDB. However, it is more useful when you can run queries that provide useful metrics about the usage of training cards aggregated across many users, and interactions. +Since interaction with training cards logs [telemetry data](/technical-overview/data/performance/telemetry), it is possible to view the data directly from CouchDB. However, it is more useful when you can run queries that provide useful metrics about the usage of training cards aggregated across many users, and interactions. -With this in mind, it is typically easier to query the data using SQL from an [analytics database]({{< ref "technical-overview/data/analytics/data-flows-for-analytics" >}}). The couchDB data can be replicated using [CHT Sync]({{< ref "/hosting/analytics" >}}) to a postgresql instance where you can then run the SQL queries. +With this in mind, it is typically easier to query the data using SQL from an [analytics database](/technical-overview/data/analytics/data-flows-for-analytics). The couchDB data can be replicated using [CHT Sync](//hosting/analytics) to a postgresql instance where you can then run the SQL queries. This guide includes several SQL queries that can act as a starting point for identifying useful metrics. diff --git a/content/en/technical-overview/data/db-schema.md b/content/en/technical-overview/data/db-schema.md index 7613592670..6eb794c4fb 100644 --- a/content/en/technical-overview/data/db-schema.md +++ b/content/en/technical-overview/data/db-schema.md @@ -42,7 +42,7 @@ In this document "record" means a JSON object that resides in CouchDB or PouchDB Contacts are either places (e.g. clinic), groupings (e.g. family) or people (e.g. a patient or CHW). The `type` property of contact records depends on the version of Medic you are running: - - If you are running 3.7 or later you get to [configure your contact hierarchy]({{< ref "building/reference/app-settings/hierarchy#app_settingsjson-contact_types" >}}), and the `type` of contacts is `contact`, and the configured type is in the `contact_type` property. + - If you are running 3.7 or later you get to [configure your contact hierarchy](/building/reference/app-settings/hierarchy#app_settingsjson-contact_types), and the `type` of contacts is `contact`, and the configured type is in the `contact_type` property. - In earlier versions the type depended on hierarchical location of the contact. There are 3 hard coded place types: `district_hospital`, `health_centre` and `clinic` and one people type `person`. These place names are often meaningless (hence the configurable contact hierarchy in later versions) to the configured project, and are textually (ie in the UI not in data structures) renamed to mean other things. For example, as `clinic` is the lowest level it is often used to represent a family. ### Places @@ -205,7 +205,7 @@ Additionally, XML reports: ## Forms -SMS forms are defined in [application config]({{< ref "building/reference/app-settings/patient_reports#app_settingsjson-patient_reports" >}}). +SMS forms are defined in [application config](/building/reference/app-settings/patient_reports#app_settingsjson-patient_reports). XML forms are stored in the database and have: - An `_id` of `form:` @@ -248,7 +248,7 @@ Users then, can be represented by up to 3 docs: ## Tasks -[Partner configuration code]({{< ref "building/tasks/tasks-js#tasksjs" >}}) running inside the Core Framework can cause tasks to appear within the Tasks tab. Each task in the tab is powered by a task document. Task documents are: +[Partner configuration code](/building/tasks/tasks-js#tasksjs) running inside the Core Framework can cause tasks to appear within the Tasks tab. Each task in the tab is powered by a task document. Task documents are: * updated only after the data for their emitting contact changes or every 7 days * created in the database for any task due within the last 60 days @@ -304,7 +304,7 @@ To understand the difference between a task requester and a task owner, kindly s ``` ## Targets -[Partner configuration code]({{< ref "building/targets/targets-js#targetsjs" >}}) can configure targets to appear within the Targets/Analytics tab. Target documents are: +[Partner configuration code](/building/targets/targets-js#targetsjs) can configure targets to appear within the Targets/Analytics tab. Target documents are: * one per analytics reporting period * updated when the user loads the application or when they view the targets tab diff --git a/content/en/technical-overview/data/performance/telemetry.md b/content/en/technical-overview/data/performance/telemetry.md index 49a5413610..a717d70ad1 100644 --- a/content/en/technical-overview/data/performance/telemetry.md +++ b/content/en/technical-overview/data/performance/telemetry.md @@ -182,7 +182,7 @@ When the aggregate doc is created the Telemetry service also includes a snapshot ### Summary data via API -To get summary data with one item per user, see the `/api/v2/export/user-devices` [API]({{< ref "building/reference/api#get-apiv2exportuser-devices" >}}), which was added in CHT 4.7.0. +To get summary data with one item per user, see the `/api/v2/export/user-devices` [API](/building/reference/api#get-apiv2exportuser-devices), which was added in CHT 4.7.0. ### Summary data via Node script diff --git a/content/en/why-the-cht/_index.md b/content/en/why-the-cht/_index.md index 7d28719b9b..8cc3e07aa4 100644 --- a/content/en/why-the-cht/_index.md +++ b/content/en/why-the-cht/_index.md @@ -5,7 +5,7 @@ weight : 1 --- {{< callout icon="sparkles" >}} - The [Community Health Toolkit](https://communityhealthtoolkit.org) is a collection of open-source technologies and open-access resources developed by a community focused on global health equity. We envision a world where primary health care is equitable, accessible, and delivered by people who are trusted in their communities. Start with the [CHT overview]({{< ref why-the-cht >}}), and join the [community forum](https://forum.communityhealthtoolkit.org/)! + The [Community Health Toolkit](https://communityhealthtoolkit.org) is a collection of open-source technologies and open-access resources developed by a community focused on global health equity. We envision a world where primary health care is equitable, accessible, and delivered by people who are trusted in their communities. Start with the [CHT overview](/why-the-cht), and join the [community forum](https://forum.communityhealthtoolkit.org/)! [![DPG Badge](https://img.shields.io/badge/Verified-DPG-3333AB?logo=data:image/svg%2bxml;base64,PHN2ZyB3aWR0aD0iMzEiIGhlaWdodD0iMzMiIHZpZXdCb3g9IjAgMCAzMSAzMyIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPHBhdGggZD0iTTE0LjIwMDggMjEuMzY3OEwxMC4xNzM2IDE4LjAxMjRMMTEuNTIxOSAxNi40MDAzTDEzLjk5MjggMTguNDU5TDE5LjYyNjkgMTIuMjExMUwyMS4xOTA5IDEzLjYxNkwxNC4yMDA4IDIxLjM2NzhaTTI0LjYyNDEgOS4zNTEyN0wyNC44MDcxIDMuMDcyOTdMMTguODgxIDUuMTg2NjJMMTUuMzMxNCAtMi4zMzA4MmUtMDVMMTEuNzgyMSA1LjE4NjYyTDUuODU2MDEgMy4wNzI5N0w2LjAzOTA2IDkuMzUxMjdMMCAxMS4xMTc3TDMuODQ1MjEgMTYuMDg5NUwwIDIxLjA2MTJMNi4wMzkwNiAyMi44Mjc3TDUuODU2MDEgMjkuMTA2TDExLjc4MjEgMjYuOTkyM0wxNS4zMzE0IDMyLjE3OUwxOC44ODEgMjYuOTkyM0wyNC44MDcxIDI5LjEwNkwyNC42MjQxIDIyLjgyNzdMMzAuNjYzMSAyMS4wNjEyTDI2LjgxNzYgMTYuMDg5NUwzMC42NjMxIDExLjExNzdMMjQuNjI0MSA5LjM1MTI3WiIgZmlsbD0id2hpdGUiLz4KPC9zdmc+Cg==)](https://www.digitalpublicgoods.net/r/community-health-toolkit) {{< /callout >}} @@ -35,12 +35,12 @@ The Core Framework makes it faster to build full-featured, scalable digital heal App developers are able to define health system roles, permissions and reporting hierarchies, and make use of five highly configurable areas of functionality: messaging, task and schedule management, decision support workflows, longitudinal person profiles, and analytics. -The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers. [Building guides and tutorials]({{< ref "building" >}}) are available to help you kick things off, and you'll also find an [active forum](https://forum.communityhealthtoolkit.org) where the community of practice comes together to support each other. +The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers. [Building guides and tutorials](/building) are available to help you kick things off, and you'll also find an [active forum](https://forum.communityhealthtoolkit.org) where the community of practice comes together to support each other. ## Offline-first technology -Digital health apps need to support health systems in a wide range of low infrastructure environments. Apps built with the Core Framework are designed to be [Offline-First]({{< ref "technical-overview/concepts/offline-first" >}}) and work with only an occasional internet connection. +Digital health apps need to support health systems in a wide range of low infrastructure environments. Apps built with the Core Framework are designed to be [Offline-First](/technical-overview/concepts/offline-first) and work with only an occasional internet connection. These apps store a user’s data locally on their device so that workflows can be completed without syncing to the server. When a connection becomes available, data will automatically sync to and from the server. Offline-first technology enables health workers to carry out important duties even when opportunities to sync may be weeks apart. As with any app, there is a limit to how much data can be stored locally, particularly on a mobile device. For users needing access to large amounts of data, online user roles are available. @@ -54,14 +54,14 @@ Apps built with the Core Framework are fully responsive Progressive Web Applicat ## Ready for national scale -Around the world, countries are adopting a model of primary health care that starts in communities and homes where high-quality, integrated services are delivered by trusted health workers who are empowered with technology. The scalability and flexibility of the CHT facilitates the creation of holistic digital community health tools that are [well integrated]({{< ref "building/interoperability" >}}) throughout the hierarchy of national health systems and across the patient continuum of care. As of 2024, six governments have selected the CHT as a tool of choice for their national community health systems. +Around the world, countries are adopting a model of primary health care that starts in communities and homes where high-quality, integrated services are delivered by trusted health workers who are empowered with technology. The scalability and flexibility of the CHT facilitates the creation of holistic digital community health tools that are [well integrated](/building/interoperability) throughout the hierarchy of national health systems and across the patient continuum of care. As of 2024, six governments have selected the CHT as a tool of choice for their national community health systems. ## Made for localization -Apps can be customized for different deployments and types of workflows. The Core Framework has been used in dozens of countries around the world with [localization settings]({{< ref "building/translations/localizing" >}}). +Apps can be customized for different deployments and types of workflows. The Core Framework has been used in dozens of countries around the world with [localization settings](/building/translations/localizing). Users can currently interact with the app in English, French, Hindi, Nepali, Spanish, Swahili, Arabic, or Indonesian and new languages can be added in the admin console. The app also supports Bikram Sambat or Gregorian calendars and localized date formatting. ## Reference apps -The Community Health Toolkit’s [Reference Apps]({{< ref "reference-apps" >}}) provide templates for structuring and organizing a community health workflow, its configuration code, and testing framework. They include a foundation for forms, data fields, and even analytics, and can be deployed as-is or easily customized by a developer for your unique context. +The Community Health Toolkit’s [Reference Apps](/reference-apps) provide templates for structuring and organizing a community health workflow, its configuration code, and testing framework. They include a foundation for forms, data fields, and even analytics, and can be deployed as-is or easily customized by a developer for your unique context. From 44247cc067e2f985f66754246bf0390f36d4467b Mon Sep 17 00:00:00 2001 From: Andra Blaj Date: Fri, 3 Oct 2025 14:51:23 +0300 Subject: [PATCH 5/5] replace .md with blank in the release page --- content/en/releases/_index.md | 258 +++++++++++++++++----------------- 1 file changed, 129 insertions(+), 129 deletions(-) diff --git a/content/en/releases/_index.md b/content/en/releases/_index.md index 55af044299..c3be319477 100644 --- a/content/en/releases/_index.md +++ b/content/en/releases/_index.md @@ -87,141 +87,141 @@ Devices with more navigation systems are more likely to get a more accurate loca ## Release Notes ### 4.x -- [4.21.1](/releases/4_21_1.md) - 2025-07-30 -- [4.21.0](/releases/4_21_0.md) - 2025-06-25 -- [4.20.1](/releases/4_20_1.md) - 2025-07-30 -- [4.20.0](/releases/4_20_0.md) - 2025-06-04 -- [4.19.0](/releases/4_19_0.md) - 2025-05-13 -- [4.18.0](/releases/4_18_0.md) - 2025-03-21 -- [4.17.0](/releases/4_17_0.md) - 2025-02-05 -- [4.16.0](/releases/4_16_0.md) - 2025-01-16 -- [4.15.0](/releases/4_15_0.md) - 2024-11-19 -- [4.14.0](/releases/4_14_0.md) - 2024-11-06 -- [4.13.0](/releases/4_13_0.md) - 2024-10-22 -- [4.12.0](/releases/4_12_0.md) - 2024-10-02 -- [4.11.0](/releases/4_11_0.md) - 2024-09-26 -- [4.10.0](/releases/4_10_0.md) - 2024-08-15 -- [4.9.0](/releases/4_9_0.md) - 2024-06-26 -- [4.8.1](/releases/4_8_1.md) - 2024-06-20 -- [4.8.0](/releases/4_8_0.md) - 2024-05-23 -- [4.7.2](/releases/4_7_2.md) - 2024-06-19 -- [4.7.1](/releases/4_7_1.md) - 2024-05-15 -- [4.7.0](/releases/4_7_0.md) - 2024-05-07 -- [4.6.0](/releases/4_6_0.md) - 2024-03-22 -- [4.5.2](/releases/4_5_2.md) - 2024-02-09 -- [4.5.1](/releases/4_5_1.md) - 2023-12-12 -- [4.5.0](/releases/4_5_0.md) - 2023-11-19 -- [4.4.2](/releases/4_4_2.md) - 2023-12-12 -- [4.4.1](/releases/4_4_1.md) - 2023-10-10 -- [4.4.0](/releases/4_4_0.md) - 2023-09-21 -- [4.3.2](/releases/4_3_2.md) - 2023-10-10 -- [4.3.1](/releases/4_3_1.md) - 2023-08-30 -- [4.3.0](/releases/4_3_0.md) - 2023-08-18 -- [4.2.4](/releases/4_2_4.md) - 2023-10-10 -- [4.2.3](/releases/4_2_3.md) - 2023-09-25 -- [4.2.2](/releases/4_2_2.md) - 2023-07-07 -- [4.2.1](/releases/4_2_1.md) - 2023-06-10 -- [4.2.0](/releases/4_2_0.md) - 2023-05-25 -- [4.1.2](/releases/4_1_2.md) - 2023-06-19 -- [4.1.1](/releases/4_1_1.md) - 2023-03-21 -- [4.1.0](/releases/4_1_0.md) - 2022-12-12 -- [4.0.1](/releases/4_0_1.md) - 2022-12-01 -- [4.0.0](/releases/4_0_0.md) - 2022-11-08 +- [4.21.1](/releases/4_21_1) - 2025-07-30 +- [4.21.0](/releases/4_21_0) - 2025-06-25 +- [4.20.1](/releases/4_20_1) - 2025-07-30 +- [4.20.0](/releases/4_20_0) - 2025-06-04 +- [4.19.0](/releases/4_19_0) - 2025-05-13 +- [4.18.0](/releases/4_18_0) - 2025-03-21 +- [4.17.0](/releases/4_17_0) - 2025-02-05 +- [4.16.0](/releases/4_16_0) - 2025-01-16 +- [4.15.0](/releases/4_15_0) - 2024-11-19 +- [4.14.0](/releases/4_14_0) - 2024-11-06 +- [4.13.0](/releases/4_13_0) - 2024-10-22 +- [4.12.0](/releases/4_12_0) - 2024-10-02 +- [4.11.0](/releases/4_11_0) - 2024-09-26 +- [4.10.0](/releases/4_10_0) - 2024-08-15 +- [4.9.0](/releases/4_9_0) - 2024-06-26 +- [4.8.1](/releases/4_8_1) - 2024-06-20 +- [4.8.0](/releases/4_8_0) - 2024-05-23 +- [4.7.2](/releases/4_7_2) - 2024-06-19 +- [4.7.1](/releases/4_7_1) - 2024-05-15 +- [4.7.0](/releases/4_7_0) - 2024-05-07 +- [4.6.0](/releases/4_6_0) - 2024-03-22 +- [4.5.2](/releases/4_5_2) - 2024-02-09 +- [4.5.1](/releases/4_5_1) - 2023-12-12 +- [4.5.0](/releases/4_5_0) - 2023-11-19 +- [4.4.2](/releases/4_4_2) - 2023-12-12 +- [4.4.1](/releases/4_4_1) - 2023-10-10 +- [4.4.0](/releases/4_4_0) - 2023-09-21 +- [4.3.2](/releases/4_3_2) - 2023-10-10 +- [4.3.1](/releases/4_3_1) - 2023-08-30 +- [4.3.0](/releases/4_3_0) - 2023-08-18 +- [4.2.4](/releases/4_2_4) - 2023-10-10 +- [4.2.3](/releases/4_2_3) - 2023-09-25 +- [4.2.2](/releases/4_2_2) - 2023-07-07 +- [4.2.1](/releases/4_2_1) - 2023-06-10 +- [4.2.0](/releases/4_2_0) - 2023-05-25 +- [4.1.2](/releases/4_1_2) - 2023-06-19 +- [4.1.1](/releases/4_1_1) - 2023-03-21 +- [4.1.0](/releases/4_1_0) - 2022-12-12 +- [4.0.1](/releases/4_0_1) - 2022-12-01 +- [4.0.0](/releases/4_0_0) - 2022-11-08 ### 3.x -- [3.17.2](/releases/3_17_2.md) - 2023-10-10 -- [3.17.1](/releases/3_17_1.md) - 2022-12-02 -- [3.17.0](/releases/3_17_0.md) - 2022-10-11 -- [3.16.1](/releases/3_16_1.md) - 2022-12-02 -- [3.16.0](/releases/3_16_0.md) - 2022-08-12 -- [3.15.0](/releases/3_15_0.md) - 2022-05-03 -- [3.14.2](/releases/3_14_2.md) - 2022-03-17 -- [3.14.1](/releases/3_14_1.md) - 2022-03-08 -- [3.14.0](/releases/3_14_0.md) - 2022-02-11 -- [3.13.0](/releases/3_13_0.md) - 2021-09-28 -- [3.12.1](/releases/3_12_1.md) - 2021-09-02 -- [3.12.0](/releases/3_12_0.md) - 2021-07-28 -- [3.11.3](/releases/3_11_3.md) - 2021-09-02 -- [3.11.2](/releases/3_11_2.md) - 2021-07-21 -- [3.11.1](/releases/3_11_1.md) - 2021-07-12 -- [3.11.0](/releases/3_11_0.md) - 2021-04-20 -- [3.10.5](/releases/3_10_5.md) - 2021-07-21 -- [3.10.4](/releases/3_10_4.md) - 2021-07-12 -- [3.10.3](/releases/3_10_3.md) - 2021-03-17 -- [3.10.2](/releases/3_10_2.md) - 2021-01-25 -- [3.10.1](/releases/3_10_1.md) - 2020-12-08 -- [3.10.0](/releases/3_10_0.md) - 2020-09-08 -- [3.9.2](/releases/3_9_2.md) - 2020-12-06 -- [3.9.1](/releases/3_9_1.md) - 2020-08-20 -- [3.9.0](/releases/3_9_0.md) - 2020-06-19 -- [3.8.2](/releases/3_8_2.md) - 2020-08-20 -- [3.8.1](/releases/3_8_1.md) - 2020-04-06 -- [3.8.0](/releases/3_8_0.md) - 2020-02-10 -- [3.7.1](/releases/3_7_1.md) - 2019-11-12 -- [3.7.0](/releases/3_7_0.md) - 2019-10-22 -- [3.6.2](/releases/3_6_2.md) - 2020-03-24 -- [3.6.1](/releases/3_6_1.md) - 2019-08-06 -- [3.6.0](/releases/3_6_0.md) - 2019-07-17 -- [3.5.0](/releases/3_5_0.md) - 2019-06-28 -- [3.4.1](/releases/3_4_1.md) - 2019-06-04 -- [3.4.0](/releases/3_4_0.md) - 2019-03-27 -- [3.3.0](/releases/3_3_0.md) - 2019-02-22 -- [3.2.1](/releases/3_2_1.md) - 2019-01-22 -- [3.2.0](/releases/3_2_0.md) - 2019-01-22 -- [3.1.0](/releases/3_1_0.md) - 2018-11-21 -- [3.0.0](/releases/3_0_0.md) - 2018-11-14 +- [3.17.2](/releases/3_17_2) - 2023-10-10 +- [3.17.1](/releases/3_17_1) - 2022-12-02 +- [3.17.0](/releases/3_17_0) - 2022-10-11 +- [3.16.1](/releases/3_16_1) - 2022-12-02 +- [3.16.0](/releases/3_16_0) - 2022-08-12 +- [3.15.0](/releases/3_15_0) - 2022-05-03 +- [3.14.2](/releases/3_14_2) - 2022-03-17 +- [3.14.1](/releases/3_14_1) - 2022-03-08 +- [3.14.0](/releases/3_14_0) - 2022-02-11 +- [3.13.0](/releases/3_13_0) - 2021-09-28 +- [3.12.1](/releases/3_12_1) - 2021-09-02 +- [3.12.0](/releases/3_12_0) - 2021-07-28 +- [3.11.3](/releases/3_11_3) - 2021-09-02 +- [3.11.2](/releases/3_11_2) - 2021-07-21 +- [3.11.1](/releases/3_11_1) - 2021-07-12 +- [3.11.0](/releases/3_11_0) - 2021-04-20 +- [3.10.5](/releases/3_10_5) - 2021-07-21 +- [3.10.4](/releases/3_10_4) - 2021-07-12 +- [3.10.3](/releases/3_10_3) - 2021-03-17 +- [3.10.2](/releases/3_10_2) - 2021-01-25 +- [3.10.1](/releases/3_10_1) - 2020-12-08 +- [3.10.0](/releases/3_10_0) - 2020-09-08 +- [3.9.2](/releases/3_9_2) - 2020-12-06 +- [3.9.1](/releases/3_9_1) - 2020-08-20 +- [3.9.0](/releases/3_9_0) - 2020-06-19 +- [3.8.2](/releases/3_8_2) - 2020-08-20 +- [3.8.1](/releases/3_8_1) - 2020-04-06 +- [3.8.0](/releases/3_8_0) - 2020-02-10 +- [3.7.1](/releases/3_7_1) - 2019-11-12 +- [3.7.0](/releases/3_7_0) - 2019-10-22 +- [3.6.2](/releases/3_6_2) - 2020-03-24 +- [3.6.1](/releases/3_6_1) - 2019-08-06 +- [3.6.0](/releases/3_6_0) - 2019-07-17 +- [3.5.0](/releases/3_5_0) - 2019-06-28 +- [3.4.1](/releases/3_4_1) - 2019-06-04 +- [3.4.0](/releases/3_4_0) - 2019-03-27 +- [3.3.0](/releases/3_3_0) - 2019-02-22 +- [3.2.1](/releases/3_2_1) - 2019-01-22 +- [3.2.0](/releases/3_2_0) - 2019-01-22 +- [3.1.0](/releases/3_1_0) - 2018-11-21 +- [3.0.0](/releases/3_0_0) - 2018-11-14 ### 2.x -- [2.18.1](/releases/2_18_1.md) - 2018-10-30 -- [2.18.0](/releases/2_18_0.md) - 2018-08-29 -- [2.17.0](/releases/2_17_0.md) - 2018-08-12 -- [2.16.1](/releases/2_16_1.md) - 2018-07-24 -- [2.16.0](/releases/2_16_0.md) - 2018-07-04 -- [2.15.0](/releases/2_15_0.md) - 2018-06-13 -- [2.14.3](/releases/2_14_3.md) - 2018-05-21 -- [2.14.2](/releases/2_14_2.md) - 2018-04-24 -- [2.14.1](/releases/2_14_1.md) - 2018-04-16 -- [2.14.0](/releases/2_14_0.md) - 2018-03-15 -- [2.13.7](/releases/2_13_7.md) - 2018-04-19 -- [2.13.6](/releases/2_13_6.md) - 2018-04-16 -- [2.13.5](/releases/2_13_5.md) - 2018-01-23 -- [2.13.4](/releases/2_13_4.md) - 2018-01-23 -- [2.13.3](/releases/2_13_3.md) - 2018-01-22 -- [2.13.2](/releases/2_13_2.md) - 2018-01-19 -- [2.13.1](/releases/2_13_1.md) - 2017-11-20 -- [2.13.0](/releases/2_13_0.md) - 2017-10-01 -- [2.12.5](/releases/2_12_5.md) - 2017-08-18 -- [2.12.4](/releases/2_12_4.md) - 2017-08-10 -- [2.12.3](/releases/2_12_3.md) - 2017-08-08 -- [2.12.2](/releases/2_12_2.md) - 2017-08-01 -- [2.12.1](/releases/2_12_1.md) - 2017-08-01 -- [2.12.0](/releases/2_12_0.md) - 2017-06-27 -- [2.11.3](/releases/2_11_3.md) - 2017-06-08 -- [2.11.2](/releases/2_11_2.md) - 2017-06-06 -- [2.11.1](/releases/2_11_1.md) - 2017-05-10 -- [2.11.0](/releases/2_11_0.md) - 2017-04-12 -- [2.10.3](/releases/2_10_3.md) - 2017-03-31 -- [2.10.2](/releases/2_10_2.md) - 2017-03-24 -- [2.10.1](/releases/2_10_1.md) - 2017-03-24 -- [2.10.0](/releases/2_10_0.md) - 2017-03-10 -- [2.9.1](/releases/2_9_1.md) - 2017-01-27 -- [2.9.0](/releases/2_9_0.md) - 2016-12-08 -- [2.8.5](/releases/2_8_5.md) - 2016-12-15 -- [2.8.4](/releases/2_8_4.md) - 2016-11-29 -- [2.8.3](/releases/2_8_3.md) - 2016-11-20 -- [2.8.2](/releases/2_8_2.md) - 2016-10-17 -- [2.8.1](/releases/2_8_1.md) - 2016-10-09 -- [2.8.0](/releases/2_8_0.md) - 2016-08-31 -- [2.7.3](/releases/2_7_3.md) - 2016-07-18 -- [2.7.2](/releases/2_7_2.md) - 2016-07-11 -- [2.7.1](/releases/2_7_1.md) - 2016-07-06 -- [2.7.0](/releases/2_7_0.md) - 2016-06-27 -- [2.6.3](/releases/2_6_3.md) - 2016-05-22 -- [2.6.2](/releases/2_6_2.md) - 2016-05-06 -- [2.6.1](/releases/2_6_1.md) - 2016-04-21 -- [2.6.0](/releases/2_6_0.md) - 2016-04-13 +- [2.18.1](/releases/2_18_1) - 2018-10-30 +- [2.18.0](/releases/2_18_0) - 2018-08-29 +- [2.17.0](/releases/2_17_0) - 2018-08-12 +- [2.16.1](/releases/2_16_1) - 2018-07-24 +- [2.16.0](/releases/2_16_0) - 2018-07-04 +- [2.15.0](/releases/2_15_0) - 2018-06-13 +- [2.14.3](/releases/2_14_3) - 2018-05-21 +- [2.14.2](/releases/2_14_2) - 2018-04-24 +- [2.14.1](/releases/2_14_1) - 2018-04-16 +- [2.14.0](/releases/2_14_0) - 2018-03-15 +- [2.13.7](/releases/2_13_7) - 2018-04-19 +- [2.13.6](/releases/2_13_6) - 2018-04-16 +- [2.13.5](/releases/2_13_5) - 2018-01-23 +- [2.13.4](/releases/2_13_4) - 2018-01-23 +- [2.13.3](/releases/2_13_3) - 2018-01-22 +- [2.13.2](/releases/2_13_2) - 2018-01-19 +- [2.13.1](/releases/2_13_1) - 2017-11-20 +- [2.13.0](/releases/2_13_0) - 2017-10-01 +- [2.12.5](/releases/2_12_5) - 2017-08-18 +- [2.12.4](/releases/2_12_4) - 2017-08-10 +- [2.12.3](/releases/2_12_3) - 2017-08-08 +- [2.12.2](/releases/2_12_2) - 2017-08-01 +- [2.12.1](/releases/2_12_1) - 2017-08-01 +- [2.12.0](/releases/2_12_0) - 2017-06-27 +- [2.11.3](/releases/2_11_3) - 2017-06-08 +- [2.11.2](/releases/2_11_2) - 2017-06-06 +- [2.11.1](/releases/2_11_1) - 2017-05-10 +- [2.11.0](/releases/2_11_0) - 2017-04-12 +- [2.10.3](/releases/2_10_3) - 2017-03-31 +- [2.10.2](/releases/2_10_2) - 2017-03-24 +- [2.10.1](/releases/2_10_1) - 2017-03-24 +- [2.10.0](/releases/2_10_0) - 2017-03-10 +- [2.9.1](/releases/2_9_1) - 2017-01-27 +- [2.9.0](/releases/2_9_0) - 2016-12-08 +- [2.8.5](/releases/2_8_5) - 2016-12-15 +- [2.8.4](/releases/2_8_4) - 2016-11-29 +- [2.8.3](/releases/2_8_3) - 2016-11-20 +- [2.8.2](/releases/2_8_2) - 2016-10-17 +- [2.8.1](/releases/2_8_1) - 2016-10-09 +- [2.8.0](/releases/2_8_0) - 2016-08-31 +- [2.7.3](/releases/2_7_3) - 2016-07-18 +- [2.7.2](/releases/2_7_2) - 2016-07-11 +- [2.7.1](/releases/2_7_1) - 2016-07-06 +- [2.7.0](/releases/2_7_0) - 2016-06-27 +- [2.6.3](/releases/2_6_3) - 2016-05-22 +- [2.6.2](/releases/2_6_2) - 2016-05-06 +- [2.6.1](/releases/2_6_1) - 2016-04-21 +- [2.6.0](/releases/2_6_0) - 2016-04-13 ### Earlier releases