chore: fix links to page sections

.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.*" \

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

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.
 

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.
 

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
 

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).
 
 
 

content/en/building/reference/app-settings/transitions.md

@@ -400,16 +400,16 @@ 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
 
 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.
 

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" >}}).

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`.

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:*