For the complete DHIS2 documentation index, see llms.txt.

2.40 Upgrade Notes¶

Please ensure you have read the upgrade notes from the PREVIOUS RELEASE, if upgrading from an earlier version

Update Dashboard¶

Lors de la mise à jour d'un Dashboard, l'utilisateur doit disposer de l'autorisation METADATA_WRITE sur le Dashboard lui-même et de l'autorisation METADATA_READ sur tous les objets référencés dans tous les DashboardItems. Les administrateurs peuvent utiliser le [partage en cascade] (https://docs.dhis2.org/en/use/user-guides/dhis-core-version-master/analysing-data/dashboards.html#cascade-sharing-of-visualizations-on-the-dashboard) pour accorder les permissions de partage requises lorsque cela est nécessaire.

Line Listing/Analytics¶

Les dates liées à la dimension temporelle "Dernière mise à jour le" prendront également en considération la date de dernière mise à jour utilisée par les clients mobiles ou d'autres clients API. En principe, la règle appliquée est la suivante : s'il existe une date de "dernière mise à jour" conservée par le client/mobile, cette date aura la priorité dans les requêtes analytiques et sera utilisée par la dimension "Dernière mise à jour le". Dans le cas contraire, elle utilisera la date de "dernière mise à jour" par défaut/usuelle côté serveur.

La dimension temporelle "Date de l'événement", qui représente la date d'exécution et peut prendre différents noms en fonction du programme/de l'étape (par exemple, "Date de la déclaration", "Date de l'événement", "Date de la visite", etc. ), affichera désormais l'horodatage en même temps que la date. Cela donnera plus de précision aux applications clientes/mobiles si nécessaire. Si aucun horodatage n'est défini, des zéros seront affichés.

API¶

A partir de la version 2.40, la propriété attributeValues dans l'API /gist est une carte d'objets avec les ID d'attributs comme clés et les valeurs simples comme valeurs. Les autres propriétés de l'attribut ne seront plus incluses dans les valeurs.
Une nouvelle colonne ounamehierarchy a été ajoutée aux tables d'analyse des événements et des inscriptions. Une exportation complète des tables d'analyse est nécessaire pour un bon fonctionnement des requêtes d'analyse, aussi bien pour les événements que pour les inscriptions.
Les API de l'ancien tracker sont obsolètes: Dans la version 2.39, les anciens points d'extrémité de l'API du tracker ont été obsolètes. (voir deprecated-features ). Nous encourageons les développeurs d'applications web et d'extensions à faire la transition et à abandonner les anciens points de terminaison. Les points de terminaison de l'API obsolètes sont les suivants :

- /api/trackedEntityInstances
- /api/enrollments
- /api/events
- /api/relationships

Use tracker endpoints instead:

- /api/tracker
- /api/tracker/enrollments
- /api/tracker/events
- /api/tracker/trackedEntities
- /api/tracker/relationships

Docs tracker endpoint | Docs old tracker endpoints

Suppression du champ status dans bundleReport: Les résumés d'importation présentent la structure générale suivante [définie ici] (https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-240/tracker.html#import-summary-structure). Le champ status dans la propriété bundleReport était redondant, il a donc été supprimé. Le champ status figurant à la racine du résumé d'importation doit être utilisé.
Renvoi du code de statut HTTP correct pour les erreurs de validation: Le code de statut 409 était renvoyé pour la plupart des erreurs de validation sur tous les points de terminaison du tracker. Désormais, un code de statut plus approprié est renvoyé dans la réponse, 400, qui représente une erreur dans la requête et que l'utilisateur doit corriger.