Data Approval Extended 1.0.0

First stable release of Data Approval Extended (formerly NHWA Approval Report).

This release turns the app into a generic, configurable data approval workflow that can be pointed at any DHIS2 dataset, with per-dataset permission groups, dataset-level settings, and a full approval / submission / revoke lifecycle driven from the dataStore.

Highlights

Generic dataset configuration

The app no longer hard-codes a specific dataset. Administrators can now register any number of datasets from a new DataSet Configurations settings screen and, for each one, configure:

• The source dataset and the matching approval (APVD) dataset.
• The data elements that store submission and approval dates.
• The SQL views used as the data source for the list (current and old periods).
• Optional behavior toggles: Submit also approves the dataSet and Revoke also marks the dataSet as incomplete.
• Six independent permission groups — Read, Complete, Incomplete, Submit, Revoke, Approve — each granting access to a set of user groups and/or individual users. Super-administrators bypass these checks automatically.

Configurations are stored in the DHIS2 dataStore under the dataset-approval namespace (DS_* keys), so they travel with the instance and can be edited by authorized users without redeploying the app.

Modification tracking restricted by Data Element Groups

Each dataset configuration can optionally enable Restrict modification display by Data Element Group sharing. When on, the modification count and the Check Difference dialog only consider data elements that belong to a DataElementGroup the current user has read access to — either directly or through one of their user groups. This lets different teams reviewing the same dataset each see only the changes relevant to them. Super-admins still see the unfiltered count.

User guide

A comprehensive user guide is now included at docs/data-approval-user-guide.md. It documents every column of the data approval list, the filter bar and Apply Filters button, the analytics-running notice, the contextual row actions, the per-dataset permission groups, and the Data Element Groups flag. A typical-workflow quick reference is included at the bottom.

Smaller improvements

• Fetching metadata for data elements is now chunked so the app no longer trips the HTTP 414 URI-too-long limit on large datasets.
• The manifest version and icon are now driven from package.json, keeping a single source of truth.
• Header bar and permission adjustments inherited from the original NHWA build remain in place.

Initial setup scripts

The app relies on two pieces of DHIS2-side metadata that have to exist before a dataset configuration can be saved from the settings UI: the approval (APVD) dataset that mirrors the source dataset's data elements, and the SQL views that power the Data Approval list. Two helper scripts in this repository automate both, so operators do not have to build them by hand.

Both scripts read DHIS2 credentials from the environment — typically a .env.local file at the repo root:

REACT_APP_DHIS2_BASE_URL=https://play.dhis2.org/your-instance
REACT_APP_DHIS2_AUTH=admin:district

yarn generate-dataset-approval — create the APVD dataset

Clones an existing source dataset into a new approval dataset by copying every data element with a -APVD suffix (trimming long names/codes so they stay within DHIS2's length limits) and adding the two date data elements the app uses to track when data is submitted and approved.

yarn generate-dataset-approval \
  --dataSet SOURCE_DS_CODE \
  --dataElement-submission SUBMIT_DATE_DE \
  --dataElement-approval APPROVAL_DATE_DE \
  --post

• --dataSet / -ds — code of the existing source dataset to clone.
• --dataElement-submission — name/code of the data element that will store the submission timestamp.
• --dataElement-approval — name/code of the data element that will store the approval timestamp.
• --post — actually commit the metadata to DHIS2. Without it the script runs in validate-only (dry-run) mode and prints what it would create, so you can safely preview it first. Warnings about trimmed names and skipped sections are written to warnings_dataelements_*.json and trimmed_names_*.json for auditing.

yarn generate-sqlviews — create the list's SQL views

Generates the per-dataset SQL views the app queries for the approval list (both current periods and old periods variants) and either writes them to disk or pushes them directly into DHIS2.

yarn generate-sqlviews \
  --dataSet SOURCE_DS_CODE \
  --dataSet-destination APVD_DS_CODE \
  --dataElement-submission SUBMIT_DATE_DE \
  --dataElement-approval APPROVAL_DATE_DE \
  --persist dhis

• --dataSet / -ds — code of the source dataset.
• --dataSet-destination / -ds-dest — code of the approval (APVD) dataset created by generate-dataset-approval.
• --dataElement-submission / -de-sub and --dataElement-approval / -de-apprv — codes of the submission and approval date data elements.
• --persist disk writes the generated SQL to local files under the repo so you can review them or pipe them into your own migration tooling. --persist dhis POSTs the SQL views directly to the DHIS2 instance and reports the created ids in sqlviews-import-report.json — those ids are what you paste into the Data Source / Old Periods Data Source fields of the dataset configuration form.

Typical end-to-end setup

1. Populate .env.local with REACT_APP_DHIS2_BASE_URL and REACT_APP_DHIS2_AUTH (format username:password).
2. Run yarn generate-dataset-approval without --post first to preview, then re-run it with --post to commit the APVD dataset.
3. Run yarn generate-sqlviews --persist dhis to create the SQL views in the instance.
4. Open DataSet Configurations in the app, create a new configuration, pick the source dataset and the APVD dataset, point the form at the two SQL views created in step 3, and set the date data elements and permission groups.
5. Load the main list — the rows for that dataset should now appear.

Upgrade notes

• First install: unzip data-approval-extended.zip into the DHIS2 App Management UI. The app will look up its configurations in the dataset-approval dataStore namespace.
• Configure at least one dataset: run the initial setup scripts above, then create a DataSet Configuration entry for each dataset you want to manage and grant permissions to the appropriate user groups. Nothing will appear in the main list until at least one configuration exists.
• Known pre-existing tsc --noEmit errors: the repository currently fails a strict tsc --noEmit pass because of the @eyeseetea/d2-api module not re-exporting some types; this does not affect the react-scripts build pipeline used by yarn build and the produced app works.

Build

Produced with yarn build. The resulting zip is installable through App Management in any DHIS2 instance that matches the platform requirements of react-scripts@4 / @dhis2/app-runtime@3.2.5.