diff --git a/.github/scripts/muffet.sh b/.github/scripts/muffet.sh index e80dee6d91..3de2697274 100755 --- a/.github/scripts/muffet.sh +++ b/.github/scripts/muffet.sh @@ -49,6 +49,7 @@ --exclude "http[s]*://www.intellisoftkenya.com.*" \ --exclude "http[s]*://demo.app.medicmobile.org.*" \ --exclude "http[s]*://www.npmjs.com.*" \ + --exclude "http[s]*://npmjs.com.*" \ --exclude "https://.*youtu.be.*" \ --exclude "https://.*youtube.com.*" \ --exclude "http[s]*://docs.couchdb.org.*" \ diff --git a/content/en/building/branding/android.md b/content/en/building/branding/android.md index 0537c59f1d..8c9e6e574f 100644 --- a/content/en/building/branding/android.md +++ b/content/en/building/branding/android.md @@ -248,7 +248,7 @@ 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](/#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 diff --git a/content/en/building/contact-management/contacts.md b/content/en/building/contact-management/contacts.md index 95d9203d09..a3b67ed5f5 100644 --- a/content/en/building/contact-management/contacts.md +++ b/content/en/building/contact-management/contacts.md @@ -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](/#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/forms/configuring/form-inputs.md b/content/en/building/forms/configuring/form-inputs.md index b3bc84cc93..30deab044d 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](/#initial-contact-data-in-contact-forms) -- [`inputs` data for user](/#user-data) -- [Contact data via contact selector](/#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 @@ -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](/#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) +- [`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 @@ -109,7 +109,7 @@ This is done by referencing an instance named `user-contact-summary`. E.g. `inst `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](/#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: @@ -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](/#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](/#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](/#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/interoperability/openhim.md b/content/en/building/interoperability/openhim.md index 0218a5e509..75eaacf197 100644 --- a/content/en/building/interoperability/openhim.md +++ b/content/en/building/interoperability/openhim.md @@ -52,7 +52,7 @@ See more information on the [CHT interoperability page](/building/interoperabili > [!NOTE] -> Users getting errors when running the following installation steps, see the [Troubleshooting guide](/#troubleshooting). +> Users getting errors when running the following installation steps, see the [Troubleshooting guide](#troubleshooting). ### Install & First Time Run diff --git a/content/en/building/reference/api.md b/content/en/building/reference/api.md index bad4bafc0b..19468b34f5 100644 --- a/content/en/building/reference/api.md +++ b/content/en/building/reference/api.md @@ -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](/#supported-properties) are supported except for `contact.parent`. Creating or modifying people through the user is not supported, see the [People section](/#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). diff --git a/content/en/building/reference/app-settings/transitions.md b/content/en/building/reference/app-settings/transitions.md index 7a88e5b801..05e8496273 100644 --- a/content/en/building/reference/app-settings/transitions.md +++ b/content/en/building/reference/app-settings/transitions.md @@ -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](/#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`](/#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 + - 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](/#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](/#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`](/#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. diff --git a/content/en/building/translations/overview.md b/content/en/building/translations/overview.md index 6fe2e3452e..966c46a0c4 100644 --- a/content/en/building/translations/overview.md +++ b/content/en/building/translations/overview.md @@ -28,7 +28,7 @@ Translations for XForms are defined within the forms themselves. The XLSForm not ### 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](/#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" >}}). diff --git a/content/en/community/contributing/code/static-analysis.md b/content/en/community/contributing/code/static-analysis.md index 1f09dedc0a..5a3c514229 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](/#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](/#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). + 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](/#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 3fd0287543..f4353a8c1f 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](/#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/workflow.md b/content/en/community/contributing/code/workflow.md index ce981e9138..48a8414958 100644 --- a/content/en/community/contributing/code/workflow.md +++ b/content/en/community/contributing/code/workflow.md @@ -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](/#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](/#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](/#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](/#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. diff --git a/content/en/community/contributing/translations.md b/content/en/community/contributing/translations.md index 3e3c113ff6..7c9fde7522 100644 --- a/content/en/community/contributing/translations.md +++ b/content/en/community/contributing/translations.md @@ -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](/#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](/#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/hosting/couch2pg/exmple-docker-deploy.md b/content/en/hosting/couch2pg/example-docker-deploy.md similarity index 99% rename from content/en/hosting/couch2pg/exmple-docker-deploy.md rename to content/en/hosting/couch2pg/example-docker-deploy.md index a2cba13199..30ccb869b3 100644 --- a/content/en/hosting/couch2pg/exmple-docker-deploy.md +++ b/content/en/hosting/couch2pg/example-docker-deploy.md @@ -6,7 +6,7 @@ description: > --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](/hosting/analytics"). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](/hosting/analytics). {{< /callout >}} This guide is for Docker Compose on Ubuntu. See related [NodeJS on Ubuntu](/hosting/couch2pg/exmple-nodejs-deploy) guide. diff --git a/content/en/hosting/couch2pg/exmple-nodejs-deploy.md b/content/en/hosting/couch2pg/example-nodejs-deploy.md similarity index 99% rename from content/en/hosting/couch2pg/exmple-nodejs-deploy.md rename to content/en/hosting/couch2pg/example-nodejs-deploy.md index b82204e800..d6bd6d6850 100644 --- a/content/en/hosting/couch2pg/exmple-nodejs-deploy.md +++ b/content/en/hosting/couch2pg/example-nodejs-deploy.md @@ -6,7 +6,7 @@ description: > --- {{< callout type="warning" >}} - CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](/hosting/analytics"). + CHT couch2pg is deprecated. For data synchronization, refer to [CHT Sync](/hosting/analytics). {{< /callout >}} This guide is for NodeJS on Ubuntu. See related [Docker Compose on Ubuntu](/hosting/couch2pg/exmple-docker-deploy) guide.