cht-conf 5.4.0 → 5.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/AGENTS.md ADDED
@@ -0,0 +1,187 @@
1
+ # AGENTS.md
2
+
3
+ ## Setup
4
+
5
+ ### Requirements
6
+
7
+ - Node.js >=20.0.0
8
+ - Python 3
9
+ - Git (for development)
10
+
11
+ ### Environment
12
+
13
+ - Docker (required for E2E tests via CHT Docker Helper)
14
+ - Internet connection (for downloading dependencies)
15
+
16
+ ### Installation
17
+
18
+ ```bash
19
+ # Install cht-conf globally
20
+ npm install -g cht-conf
21
+
22
+ # Install required Python dependency
23
+ pip install git+https://github.com/medic/pyxform.git@medic-conf-1.17#egg=pyxform-medic
24
+
25
+ # For local development
26
+ git clone https://github.com/medic/cht-conf.git
27
+ cd cht-conf
28
+ npm ci
29
+ ```
30
+
31
+
32
+ ## Build & Test
33
+
34
+ ```bash
35
+ # Code Quality
36
+ npm run eslint # Run linting checks
37
+
38
+ # Testing
39
+ npm test # Run unit tests with Mocha and NYC coverage
40
+ npm run test-e2e # Run end-to-end tests (requires Docker)
41
+
42
+ # Build and Maintenance
43
+ npm run clean # Clean build directory
44
+
45
+ # Development
46
+ node src/bin/index.js <actions> # Run locally for development
47
+ ```
48
+
49
+ ## Project Structure
50
+
51
+ ```
52
+ cht-conf/
53
+ ├── bin/ # Binary executables used by the application
54
+ ├── src/ # Source code
55
+ │ ├── bin/ # Entry point scripts and shell integrations
56
+ │ ├── cli/ # Command-line interface code
57
+ │ ├── contact-summary/ # Contact summary utilities
58
+ │ ├── fn/ # Core functionality implementations (actions)
59
+ │ ├── lib/ # Shared libraries and utilities
60
+ │ │ └── validation/ # Form validation modules
61
+ │ └── nools/ # Rule engine related code
62
+ └── test/ # Test code
63
+ ├── contact-summary/ # Tests for contact summary features
64
+ ├── e2e/ # End-to-end tests
65
+ ├── fn/ # Tests for core functionality
66
+ ├── lib/ # Tests for shared libraries
67
+ └── nools/ # Tests for nools rules
68
+ ```
69
+
70
+ ## Code Conventions
71
+
72
+ ### Action Module Pattern
73
+
74
+ Files in `src/fn/` use this pattern:
75
+
76
+ ```javascript
77
+ module.exports = {
78
+ requiresInstance: true, // Whether connection to CHT is needed
79
+ execute: async () => {
80
+ // Implementation
81
+ },
82
+ };
83
+ ```
84
+
85
+ ### Form Validation Pattern
86
+
87
+ Files in `src/lib/validation/form/` use this pattern:
88
+
89
+ ```javascript
90
+ module.exports = {
91
+ requiresInstance: false,
92
+ skipFurtherValidation: true,
93
+ execute: async ({ xformPath, xmlStr, xmlDoc, apiVersion }) => {
94
+ // Implementation
95
+ },
96
+ };
97
+ ```
98
+
99
+ ### Code Style
100
+
101
+ - ESLint enforces:
102
+ - ES2022 syntax
103
+ - Single quotes (template literals allowed)
104
+ - Semicolons required
105
+ - No console logging
106
+ - Strict equality (===)
107
+ - Extends @medic ESLint config
108
+ - EditorConfig settings:
109
+ - 2-space indentation
110
+ - LF line endings
111
+ - UTF-8 encoding
112
+ - Final newline in files
113
+
114
+ ### Testing Framework
115
+
116
+ - Mocha for test runner
117
+ - Chai for assertions (with chai-as-promised and other plugins)
118
+ - NYC for code coverage
119
+ - Sinon for mocks and stubs
120
+ - Tests mirror the src directory structure
121
+ - E2E tests use CHT Docker Helper
122
+
123
+ ## PR & CI Guidelines
124
+
125
+ ### Commit Format
126
+
127
+ The project uses [Conventional Commits](https://www.conventionalcommits.org/) enforced by commitlint:
128
+
129
+ ```
130
+ feat(scope): add new feature
131
+ fix(scope): fix bug
132
+ docs(scope): update documentation
133
+ chore(scope): update tooling
134
+ ```
135
+
136
+ ### Branches
137
+
138
+ - Main branch: `main`
139
+ - PRs should be created against the `main` branch
140
+
141
+ ### CI Process
142
+
143
+ GitHub Actions workflow runs:
144
+
145
+ - Lint checks (`npm run eslint`)
146
+ - Unit tests (`npm test`)
147
+ - E2E tests (`npm run test-e2e`)
148
+ - Tests across multiple Node.js versions (20.x, 22.x, 24.x)
149
+
150
+ ### Semantic Versioning
151
+
152
+ The project uses semantic-release for automated versioning based on commit messages.
153
+
154
+ ## Notes for AI Agents
155
+
156
+ - Use `npm test` for unit tests and `npm run test-e2e` for integration tests.
157
+ - All new code should include corresponding tests in the mirrored `test/` directory.
158
+ - Follow the Action Module Pattern for new functionality in `src/fn/`.
159
+ - Form validation modules should follow the Form Validation Pattern in `src/lib/validation/form/`.
160
+ - PRs must pass CI (lint + tests) before merging.
161
+ - All commits should follow the Conventional Commits format.
162
+
163
+ ## Security Considerations
164
+
165
+ - Do not commit secrets or environment variables.
166
+ - Use the provided API abstractions in `src/lib/` rather than direct connections.
167
+ - Follow project ESLint rules to avoid unsafe code patterns.
168
+ - Authentication credentials should be handled securely through the CLI parameters.
169
+
170
+ ## CLI Usage
171
+
172
+ ```bash
173
+ # Default workflow with local CHT instance
174
+ cht --local
175
+
176
+ # Specific action
177
+ cht --local upload-app-forms
178
+
179
+ # Filter forms
180
+ cht --local upload-app-forms -- form1 form2
181
+
182
+ # Archive mode
183
+ cht --archive --destination=<path>
184
+
185
+ # Run locally for development
186
+ node src/bin/index.js <action>
187
+ ```
package/CHANGELOG.md CHANGED
@@ -1,3 +1,17 @@
1
+ # [5.6.0](https://github.com/medic/cht-conf/compare/v5.5.0...v5.6.0) (2025-12-15)
2
+
3
+
4
+ ### Features
5
+
6
+ * **#772:** allow multiple sms recipients ([3647c7c](https://github.com/medic/cht-conf/commit/3647c7c18003280e7c461b63eac6466221e2474e)), closes [#772](https://github.com/medic/cht-conf/issues/772)
7
+
8
+ # [5.5.0](https://github.com/medic/cht-conf/compare/v5.4.0...v5.5.0) (2025-10-08)
9
+
10
+
11
+ ### Features
12
+
13
+ * **#753:** add deprecated `tel` type form validation ([#754](https://github.com/medic/cht-conf/issues/754)) ([e701b69](https://github.com/medic/cht-conf/commit/e701b691823e535d71e460f0300624642dafe270)), closes [#753](https://github.com/medic/cht-conf/issues/753)
14
+
1
15
  # [5.4.0](https://github.com/medic/cht-conf/compare/v5.3.0...v5.4.0) (2025-09-11)
2
16
 
3
17
 
package/README.md CHANGED
@@ -1,360 +1,16 @@
1
- CHT App Configurer
2
- ========================
1
+ # CHT Conf
2
+ ![GitHub license](https://img.shields.io/github/license/medic/cht-conf)
3
+ ![GitHub release](https://img.shields.io/github/v/release/medic/cht-conf)
4
+ [![Discourse](https://img.shields.io/badge/discourse-join-blue)](https://forum.communityhealthtoolkit.org/)
3
5
 
4
- CHT Conf is a command-line interface tool to manage and configure your apps built using the [Core Framework](https://github.com/medic/cht-core) of the [Community Health Toolkit](https://communityhealthtoolkit.org).
6
+ 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).
5
7
 
6
- # Requirements
8
+ Instructions on how to use this tool can be found on [the CHT documentation site](https://docs.communityhealthtoolkit.org/community/contributing/code/cht-conf/).
7
9
 
8
- * nodejs 18 or later
9
- * python 3
10
- * or Docker
11
-
12
- # Installation
13
-
14
- ## Operating System Specific
15
-
16
- ### Ubuntu
17
-
18
- npm install -g cht-conf
19
- sudo python -m pip install git+https://github.com/medic/pyxform.git@medic-conf-1.17#egg=pyxform-medic
20
-
21
- ### OSX
22
-
23
- npm install -g cht-conf
24
- pip install git+https://github.com/medic/pyxform.git@medic-conf-1.17#egg=pyxform-medic
25
-
26
- ### Windows
27
-
28
- As Administrator:
29
-
30
- npm install -g cht-conf
31
- python -m pip install git+https://github.com/medic/pyxform.git@medic-conf-1.17#egg=pyxform-medic --upgrade
32
-
33
- ### Docker
34
-
35
- CHT Conf can also be run from within a Docker container. This is useful if you are already familiar with Docker and do not wish to configure the various dependencies required for developing CHT apps on your local machine. The necessary dependencies are pre-packaged in the Docker image.
36
-
37
- #### Using the image
38
-
39
- The Docker image can be used as a [VS Code Development Container](https://code.visualstudio.com/docs/devcontainers/containers) (easiest) or as a standalone Docker utility.
40
-
41
- Install [Docker](https://www.docker.com/). If you are using Windows, you also need to enable the [Windows Subsystem for Linux (WSL2)](https://learn.microsoft.com/en-us/windows/wsl/install) to perform the following steps.
42
-
43
- ##### VS Code Development Container
44
-
45
- If you want to develop CHT apps with VS Code, you can use the Docker image as a Development Container. This will allow you to use the `cht` utility and its associated tech stack from within VS Code (without needing to install dependencies like NodeJS on your host system).
46
-
47
- See the [CHT Documentation](https://docs.communityhealthtoolkit.org/apps/tutorials/local-setup/#developing-with-vs-code-dev-container) for more information on building CHT apps with VS Code Development Containers.
48
-
49
- ##### Standalone Docker utility
50
-
51
- If you are not using VS Code, you can use the Docker image as a standalone utility from the command line. Instead of using the `cht ...` command, you can run `docker run -it --rm -v "$PWD":/workdir medicmobile/cht-app-ide ...`. This will create an ephemeral container with access to your current directory that will run the given cht command. (Do not include the `cht` part of the command, just your desired actions/parameters.)
52
-
53
- Run the following command inside the project directory to bootstrap your new CHT project:
54
-
55
- ```shell
56
- docker run -it --rm -v "$PWD":/workdir medicmobile/cht-app-ide initialise-project-layout
57
- ```
58
-
59
- #### Note on connecting to a local CHT instance
60
-
61
- When using `cht` 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").
62
-
63
- It is recommended to run a local CHT instance using the [CHT Docker Helper script](https://docs.communityhealthtoolkit.org/apps/guides/hosting/4.x/app-developer/). You can connect to the resulting `...my.local-ip.co` 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).
64
-
65
- ## Bash completion
66
-
67
- To enable tab completion in bash, add the following to your `.bashrc`/`.bash_profile`:
68
-
69
- eval "$(cht --shell-completion=bash)"
70
-
71
- ## Zsh completion
72
- To enable tab completion in zsh, add the following to your `~/.zshrc` file:
73
-
74
- eval "$(cht --shell-completion=zsh)"
75
-
76
- ## Upgrading
77
-
78
- To upgrade to the latest version
79
-
80
- npm install -g cht-conf
81
-
82
- ## Usage
83
-
84
- `cht` will upload the configuration **from your current directory**.
85
-
86
- ## Specifying the server to configure
87
-
88
- If you are using the default actionset, or performing any actions that require a CHT instance to function (e.g. `upload-xyz` or `backup-xyz` actions) you must specify the server you'd like to function against.
89
-
90
- ### localhost
91
-
92
- For developers, this is the instance defined in your `COUCH_URL` environment variable.
93
-
94
- cht --local
95
-
96
- ### A specific Medic-hosted instance
97
-
98
- For configuring Medic-hosted instances.
99
-
100
- cht --instance=instance-name.dev
101
-
102
- Username `admin` is used. A prompt is shown for entering password.
103
-
104
- If a different username is required, add the `--user` switch:
105
-
106
- --user user-name --instance=instance-name.dev
107
-
108
- ### An arbitrary URL
109
-
110
- cht --url=https://username:password@example.com:12345
111
-
112
- **NB** - When specifying the URL with `--url`, be sure not to specify the CouchDB database name in the URL. The CHT API will find the correct database.
113
-
114
- ### Using a session token for authentication
115
-
116
- CHT Conf supports authentication using a session token by adding `--session-token` parameter:
117
-
118
- cht --url=https://example.com:12345 --session-token=*my_token*
119
-
120
- The `my_token` can be obtained by doing a POST request to `/_session` [endpoint](https://docs.couchdb.org/en/stable/api/server/authn.html#cookie-authentication) with `name` and `password` as form parameters.
121
-
122
- For example, if your CHT instance is `my.cht.com`, you could use this `curl` call to specify your user `medic` and your password `secret123` to retrieve the header with the `AuthSession` value which is the token:
123
-
124
- ```
125
- curl -v -H 'Content-Type: application/json' -d '{"name":"medic","password":"secret123"}' https://my.cht.com/_session 2>&1 | grep AuthSession
126
- < set-cookie: AuthSession=bWVkaWM6NjdBRTM4MkE6EguRnzpSiK0t8wFaOQ_jgkZE8UWcgNWgpyStzbbHreI; Version=1; Expires=Fri, 13-Feb-2026 18:21:30 GMT; Max-Age=31536000; Path=/; HttpOnly
127
- ```
128
- ### Into an archive to be uploaded later
129
-
130
- cht --archive
131
-
132
- The resulting archive is consumable by CHT API >v3.7 to create default configurations.
133
-
134
- ## Perform specific action(s)
135
-
136
- cht <--archive|--local|--instance=instance-name|--url=url> <...action>
137
-
138
- The list of available actions can be seen via `cht --help`.
139
-
140
- ## Perform actions for specific forms
141
-
142
- cht <--local|--instance=instance-name|--url=url> <...action> -- <...form>
143
-
144
- ## Protecting against configuration overwriting
145
-
146
- _Added in v3.2.0_
147
-
148
- In order to avoid overwriting someone else's configuration cht-conf records the last uploaded configuration snapshot in the `.snapshots` directory. The `remote.json` file should be committed to your repository along with the associated configuration change. When uploading future configuration if cht-conf detects the snapshot doesn't match the configuration on the server you will be prompted to overwrite or cancel.
149
-
150
- # Currently supported
151
-
152
- ## Settings
153
-
154
- * compile app settings from:
155
- - tasks
156
- - rules
157
- - schedules
158
- - contact-summary
159
- - purge
160
- * app settings can also be defined in a more modular way by having the following files in app_settings folder:
161
- - base_settings.json
162
- - forms.json
163
- - schedules.json
164
- * backup app settings from server
165
- * upload app settings to server
166
- * upload resources to server
167
- * upload custom translations to the server
168
- * upload privacy policies to server
169
- * upload branding to server
170
- * upload partners to server
171
- * upload database indexes to server
172
-
173
- ## Forms
174
-
175
- * fetch from Google Drive and save locally as `.xlsx`
176
- * backup from server
177
- * delete all forms from server
178
- * delete specific form from server
179
- * upload all app or contact forms to server
180
- * upload specified app or contact forms to server
181
-
182
- ## Managing data and images
183
-
184
- * convert CSV files with contacts and reports to JSON docs
185
- * move contacts by downloading and making the changes locally first
186
- * upload JSON files as docs on instance
187
- * compress PNGs and SVGs in the current directory and its subdirectories
188
-
189
- ## Editing contacts across the hierarchy.
190
- To edit existing couchdb documents, create a CSV file that contains the id's of the document you wish to update, and the columns of the document attribute(s) you wish to add/edit. By default, values are parsed as strings. To parse a CSV column as a JSON type, refer to the [Property Types](#property-types) section to see how you can parse the values to different types. Also refer to the [Excluded Columns](#excluded-columns) section to see how to exclude column(s) from being added to the docs.
191
-
192
- Parameter | Description | Required
193
- -- | -- | --
194
- column(s) | Comma delimited list of columns you wish to add/edit. If this is not specified all columns will be added. | No
195
- docDirectoryPath | This action outputs files to local disk at this destination | No. Default `json-docs`
196
- file(s) | Comma delimited list of files you wish to process using edit-contacts. By default, contact.csv is searched for in the current directory and processed. | No.
197
- updateOfflineDocs | If passed, this updates the docs already in the docDirectoryPath instead of downloading from the server. | No.
198
-
199
-
200
- ### Example
201
- 1. Create a contact.csv file with your columns in the csv folder in your current path. The documentID column is a requirement. (The documentID column contains the document IDs to be fetched from couchdb.)
202
-
203
- | documentID | is_in_emnch:bool |
204
- | ----------------- | ---------------- |
205
- | documentID1 | false |
206
- | documentID2 | false |
207
- | documentID3 | true |
208
-
209
- 1. Use the following command to download and edit the documents:
210
-
211
- ```
212
- cht --instance=*instance* edit-contacts -- --column=*is_in_emnch* --docDirectoryPath=*my_folder*
213
- ```
214
- or this one to update already downloaded docs
215
- ```
216
- cht --instance=*instance* edit-contacts -- --column=*is_in_emnch* --docDirectoryPath=*my_folder* --updateOfflineDocs
217
- ```
218
- 1. Then upload the edited documents using the [upload-docs ](#examples) command.
219
-
220
-
221
- # Project layout
222
-
223
- This tool expects a project to be structured as follows:
224
-
225
- example-project/
226
- .eslintrc
227
- app_settings.json
228
- contact-summary.js
229
- privacy-policies.json
230
- privacy-policies/
231
- language1.html
232
- …
233
- purge.js
234
- resources.json
235
- resources/
236
- icon-one.png
237
- …
238
- targets.js
239
- tasks.js
240
- task-schedules.json
241
- forms/
242
- app/
243
- my_project_form.xlsx
244
- my_project_form.xml
245
- my_project_form.properties.json
246
- my_project_form-media/
247
- [extra files]
248
- …
249
- contact/
250
- person-create.xlsx
251
- person-create.xml
252
- person-create-media/
253
- [extra files]
254
- …
255
- …
256
- …
257
- translations/
258
- messages-xx.properties
259
- …
260
-
261
- If you are starting from scratch you can initialise the file layout using the `initialise-project-layout` action:
262
-
263
- cht initialise-project-layout
264
-
265
- ## Derived configs
266
-
267
- Configuration can be inherited from another project, and then modified. This allows the `app_settings.json` and contained files (`task-schedules.json`, `targets.json` etc.) to be imported, and then modified.
268
-
269
- To achieve this, create a file called `settings.inherit.json` in your project's root directory with the following format:
270
-
271
- {
272
- "inherit": "../path/to/other/project",
273
- "replace": {
274
- "keys.to.replace": "value-to-replace-it-with"
275
- },
276
- "merge": {
277
- "complex.objects": {
278
- "will_be_merged": true
279
- }
280
- },
281
- "delete": [
282
- "all.keys.listed.here",
283
- "will.be.deleted"
284
- ],
285
- "filter": {
286
- "object.at.this.key": [
287
- "will",
288
- "keep",
289
- "only",
290
- "these",
291
- "properties"
292
- ]
293
- }
294
- }
295
-
296
- # Development
297
-
298
- To develop a new action or improve an existing one, check the ["Actions" doc](src/fn/README.md).
299
-
300
- ## Testing
301
-
302
- ### Unit tests
303
-
304
- Execute `npm test` to run static analysis checks and the test suite. Requires Docker to run integration tests against a CouchDB instance.
305
-
306
- ### End-to-end tests
307
-
308
- Run `npm run test-e2e` to run the end-to-end test suite against an actual CHT instance locally. These tests rely on [CHT Docker Helper](https://docs.communityhealthtoolkit.org/hosting/4.x/app-developer/#cht-docker-helper-for-4x) to spin up and tear down an instance locally.
309
-
310
- The code interfacing with CHT Docker Helper lives in [`test/e2e/cht-docker-utils.js`](./test/e2e/cht-docker-utils.js). You should rely on the API exposed by this file to orchestrate CHT instances for testing purposes. It is preferable to keep the number of CHT instances orchestrated in E2E tests low as it takes a non-negligible amount of time to spin up an instance and can quickly lead to timeouts.
311
-
312
- ## Executing your local branch
313
-
314
- 1. Clone the project locally
315
- 1. Make changes to cht-conf or checkout a branch for testing
316
- 1. Test changes
317
- 1. To test CLI changes locally you can run `node <project_dir>/src/bin/index.js`. This will run as if you installed via npm.
318
- 1. To test changes that are imported in code run `npm install <project_dir>` to use the local version of cht-conf.
319
-
320
- ## Releasing
321
-
322
- 1. Create a pull request with prep for the new release.
323
- 1. Get the pull request reviewed and approved.
324
- 1. When doing the squash and merge, make sure that your commit message is clear and readable and follows the strict format described in the commit format section below. If the commit message does not comply, automatic release will fail.
325
- 1. In case you are planning to merge the pull request with a merge commit, make sure that every commit in your branch respects the format.
326
-
327
- ### Commit format
328
- The commit format should follow this [conventional-changelog angular preset](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular). Examples are provided below.
329
-
330
- Type | Example commit message | Release type
331
- -- | -- | --
332
- Bug fixes | fix(#123): infinite spinner when clicking contacts tab twice | patch
333
- Performance | perf(#789): lazily loaded angular modules | patch
334
- Features | feat(#456): add home tab | minor
335
- Non-code | chore(#123): update README | none
336
- Breaking| perf(#2): remove reporting rates feature <br/> BREAKING CHANGE: reporting rates no longer supported | major
337
-
338
-
339
-
340
- ### Releasing betas
341
-
342
- 1. Checkout the default branch, for example `main`
343
- 1. Run `npm version --no-git-tag-version <major>.<minor>.<patch>-beta.1`. This will only update the versions in `package.json` and `package-lock.json`. It will not create a git tag and not create an associated commit.
344
- 1. Run `npm publish --tag beta`. This will publish your beta tag to npm's beta channel.
345
-
346
- To install from the beta channel, run `npm install cht-conf@beta`.
347
-
348
- ## Build status
349
-
350
- Builds brought to you courtesy of GitHub actions.
351
-
352
- <img src="https://github.com/medic/cht-conf/actions/workflows/build.yml/badge.svg">
353
-
354
- # Copyright
10
+ ## Copyright
355
11
 
356
12
  Copyright 2013-2025 Medic Mobile, Inc. <hello@medic.org>
357
13
 
358
- # License
14
+ ## License
359
15
 
360
16
  The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "cht-conf",
3
- "version": "5.4.0",
3
+ "version": "5.6.0",
4
4
  "description": "Configure CHT deployments",
5
5
  "main": "./src/lib/main.js",
6
6
  "engines": {
@@ -37,13 +37,13 @@
37
37
  "@xmldom/xmldom": "^0.8.10",
38
38
  "async-retry": "^1.3.3",
39
39
  "canonical-json": "0.0.4",
40
- "csv-parse": "^5.6.0",
40
+ "csv-parse": "^6.1.0",
41
41
  "dom-compare": "^0.6.0",
42
42
  "eslint": "^8.57.1",
43
43
  "eslint-webpack-plugin": "^4.2.0",
44
44
  "googleapis": "^144.0.0",
45
45
  "iso-639-1": "^3.1.5",
46
- "joi": "^17.13.3",
46
+ "joi": "^18.0.1",
47
47
  "json-diff": "^1.0.6",
48
48
  "json-stringify-safe": "^5.0.1",
49
49
  "json2csv": "^5.0.7",
@@ -63,16 +63,16 @@
63
63
  "redact-basic-auth": "^1.0.1",
64
64
  "request": "^2.88.2",
65
65
  "request-promise-native": "^1.0.9",
66
- "semver": "^7.7.1",
67
- "svgo": "^3.3.2",
66
+ "semver": "^7.7.3",
67
+ "svgo": "^4.0.0",
68
68
  "terser-webpack-plugin": "^5.3.11",
69
69
  "uuid": "^11.1.0",
70
- "webpack": "^5.98.0",
70
+ "webpack": "^5.102.1",
71
71
  "xpath": "0.0.34"
72
72
  },
73
73
  "devDependencies": {
74
- "@commitlint/cli": "^19.7.1",
75
- "@commitlint/config-conventional": "^19.7.1",
74
+ "@commitlint/cli": "^20.1.0",
75
+ "@commitlint/config-conventional": "^20.0.0",
76
76
  "@medic/eslint-config": "^1.1.0",
77
77
  "@semantic-release/changelog": "^6.0.3",
78
78
  "@semantic-release/git": "^10.0.1",
@@ -82,16 +82,16 @@
82
82
  "chai-exclude": "^2.1.1",
83
83
  "chai-shallow-deep-equal": "^1.4.6",
84
84
  "chai-xml": "^0.4.1",
85
- "eslint-plugin-n": "^17.15.1",
85
+ "eslint-plugin-n": "^17.23.1",
86
86
  "express": "^4.21.2",
87
87
  "express-pouchdb": "^4.2.0",
88
- "fs-extra": "11.3.0",
88
+ "fs-extra": "11.3.2",
89
89
  "husky": "^9.1.7",
90
- "mocha": "^11.1.0",
90
+ "mocha": "^11.7.5",
91
91
  "nyc": "^17.1.0",
92
92
  "pouchdb-adapter-memory": "^9.0.0",
93
- "rewire": "^8.0.0",
94
- "semantic-release": "^24.2.4",
93
+ "rewire": "^9.0.1",
94
+ "semantic-release": "^25.0.2",
95
95
  "sinon": "^21.0.0"
96
96
  }
97
97
  }
@@ -58,7 +58,7 @@ const ScheduleSchema = joi.array().items(
58
58
  offset: joi.string().required(),
59
59
  send_day: joi.string().allow(''),
60
60
  send_time: joi.string().allow(''),
61
- recipient: joi.string()
61
+ recipient: joi.alternatives().try(joi.string(), joi.array())
62
62
  })
63
63
  ).required()
64
64
  })
@@ -0,0 +1,36 @@
1
+ const semver = require('semver');
2
+ const { getBindNodes } = require('../../forms-utils');
3
+
4
+ const validateDeprecatedTelType = async({xformPath, xmlDoc, apiVersion}) => {
5
+ if(!apiVersion)
6
+ {
7
+ return {errors:[], warnings:[]};
8
+ }
9
+
10
+ if(semver.lt(apiVersion, '4.11.0'))
11
+ {
12
+ return {errors:[], warnings:[]};
13
+ }
14
+
15
+ const warnings = [];
16
+
17
+ const telNodesets = getBindNodes(xmlDoc)
18
+ .filter(bind => bind.getAttribute('type') === 'tel')
19
+ .map(bind => bind.getAttribute('nodeset'))
20
+ .filter(Boolean);
21
+
22
+ if(telNodesets.length)
23
+ {
24
+ warnings.push(
25
+ `Form at ${xformPath} contains the following phone number fields with the deprecated 'tel' type [${telNodesets.join(', ')}]. Follow the documentation to update these fields to the supported type:\nhttps://docs.communityhealthtoolkit.org/building/forms/app/#phone-number-input`
26
+ );
27
+ }
28
+
29
+ return {errors:[], warnings};
30
+ };
31
+
32
+ module.exports = {
33
+ requiresInstance: true,
34
+ skipFurtherValidation: false,
35
+ execute: validateDeprecatedTelType
36
+ };