[FIX] v43 scope legacy app tutorials to the DHIS2 versions that ship those apps

[anagperal]

📌 References

• Issue: Closes #869djm0wn [v43 upgrade] Generic apps v43 upgrade investigation & #869ee89h6 training-app v43

📝 Implementation

• The data-entry, tracker-capture and pivot-tables bundled modules pointed at apps that are no longer part of the DHIS2 core, so the tutorial iframe loaded a 404 on recent instances. dhis-web-pivot was folded into Data Visualizer in 2.37; dhis-web-dataentry and dhis-web-tracker-capture were retired in 2.42.

• Set dhisVersionRange inside each module zip so they are only offered on the versions that actually ship those apps:

  Module	Range	Hidden from
  data-entry	2.30–2.41	2.42
  tracker-capture	2.30–2.41	2.42
  pivot-tables	2.30–2.36	2.37

• Bumped their revision in public/modules/config.json (7 → 8) so instances that already imported them pick up the change on next load. The zips and config.json must ship together: if the bump reaches an instance without the corrected zips, it re-imports the old module at revision 8 and the real fix no longer propagates.

• The auto-update only reaches modules that are not locally edited: listAll partitions outdated modules by their dirty flag and re-imports only the clean ones, flagging the rest with a "There's a new version of this module, please reset to default values to update" warning. On instances where these three modules were never customised — the default — the fix applies without manual intervention. Instances that customised any of them will need a manual reset to default values.

• One code change: added 2.43 to the dhisVersions selector in GeneralInfoStep.tsx, which stopped at 2.42 — modules with an explicit version range could not be marked compatible with v43 and were hidden there

• No tutorial content, dhisLaunchUrl or dhisAuthorities is modified — all remain correct for the versions each module is now scoped to.

• Resulting behaviour: incompatible modules disappear from the landing page, but stay listed in Settings → Modules with a "Module does not support this DHIS2 version" warning, so admins keep visibility and control.

🚧 Pending product decision (not addressed in this PR)

This PR hides the legacy modules; it does not replace them. From 2.42 onwards users have no Data Entry or Tracker Capture tutorial at all. Three decisions are needed to fill that gap.

Decision 1 — Aggregate Data Entry (the app that replaced the legacy one). No module exists for it. Creating one means new tutorial content recorded against the new UI, plus a new module with authority M_dhis-web-aggregate-data-entry and url /dhis-web-aggregate-data-entry/index.html. It should not reuse the data-entry id: that would swap the content under existing users while keeping their old progress, and landing pages reference modules by id. Suggested id: aggregate-data-entry.

Decision 2 — Tracker programs in Capture. The bundled Capture module (event-capture) covers event programs only; its 8 steps are all event workflows. Tracker workflows are uncovered from 2.42 onwards, now that Tracker Capture is gone. Either extend event-capture with tracker steps, or add a separate module pointing at the same app. A separate module keeps per-module progress meaningful (an 18-step module gives misleading completion percentages to someone who only cares about tracker) and preserves the landing-page slot where the old Tracker Capture tile used to sit.

Decision 3 — Naming, only relevant once 1 or 2 lands. With the new modules left unscoped (see the constraint below), both the legacy and the new Data Entry module are visible on 2.39–2.41. That is correct rather than a duplicate — both apps genuinely ship in those versions and a user may be on either — and the overlap closes by itself at 2.42. If it is judged confusing in the meantime, the fix is naming, not version scoping: rename the old ones to "Data Entry (legacy)" and "Tracker Capture (legacy)". Cost to weigh: name is a TranslatableText, so a rename means redoing the es/fr translations and bumping the module revision again.

⚠️ Constraint that applies to whichever option is chosen

Leave dhisVersionRange empty on any new module. Do not fill in the version selector, even though the field is right there in the creation wizard and this PR does the opposite for the legacy modules.

What reads as "2.30–2.41" in the table above is really the string "2.30,2.31,2.32,…,2.41" spelled out in full. There is no way to express "2.42 and above." So a new module scoped to "2.42,2.43" disappears from every instance the day DHIS2 44 ships, and bringing it back requires a code change, a repackaged zip, a revision bump and an app release — on every DHIS2 release, forever. That treadmill is exactly the bug this PR's code change fixes: the selector had stopped at 2.42.

With the field left empty, dhisAuthorities does the gating instead, and it maintains itself: M_dhis-web-aggregate-data-entry does not exist on older instances, so no user holds it and the module is filtered out. When DHIS2 retires an app, its authority goes with it and the module hides itself. No code change ever.

Two things to be aware of, neither of which changes the recommendation:

• Superusers (authority ALL) bypass the authority filter, so they will see the module on instances where the app is absent. Cosmetic, and limited to one class of user.

Why this PR does the opposite for the legacy modules — not a contradiction, an asymmetry. Their version list is closed forever (those apps are never coming back), so it never needs editing. And authorities would not work for them: M_dhis-web-tracker-capture still exists in v43, so the authority filter hides nothing — that is precisely the "tile visible, opens a blank iframe" symptom this PR fixes. Closed list → enumerate versions. Open-ended list → let authorities gate.

📹 Screenshots/Screen capture

NEW:

Screencast.from.2026-07-22.09-23-44.webm

OLD:

Screencast.from.2026-07-22.09-26-31.webm

🔥 How to test it? (If there is any special consideration or the reviewer does not know how to test it)

Build the app and check old modules do not appear and in settings page they have a warning message

📑 Others

• Any change in the API repo? If so, what branch/PR?
• Any change in the GUI library? If so, what branch/PR?

[bundlemon]

BundleMon

No change in files bundle size

Groups updated (1)

Status	Path	Size	Limits
✅	Build Folder ./**/*	10.47MB (+222B 0%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history