2.37 Upgrade Notes¶
Please ensure you have read the upgrade notes from the PREVIOUS RELEASE, if upgrading from an earlier version
Database¶
API¶
- Se elimina el endpoint API
/api/userCredentials. Los usuarios de la API deben utilizar los endpoints API/api/usersy/api/userLookupen su lugar. - Se eliminan las API relacionadas con gráficos (
/api/charts) y tablas de informes (/api/reportTables). Los consumidores deberán utilizar en su lugar la API de visualización (/api/visualizations). Otros endpoints existentes que hacen algún tipo de referencia a gráficos y tablas de informes ahora harán referencia a visualización.
Authorities¶
- La autoridad
F_GENERATE_MIN_MAX_VALUESexistente es ahora requerida para generar valores min-max en la aplicación administración de datos. Anteriormente se requeríaF_PERFORM_MAINTENANCE. - La creación de niveles de aprobación de datos requiere la autoridad
F_DATA_APPROVAL_LEVEL. - La creación de flujos de trabajo de aprobación de datos requiere la autoridad
F_DATA_APPROVAL_WORKFLOW.
Audit¶
In 2.38 we will be changing the default location of audits from the database to a logfile called dhis-audits.log. If you don't want this behavior and want to be futureproof it's recommended that you add these lines to your dhis.conf:
audit.database = on
audit.logger = off
Patch-specific Changes¶
2.37.5¶
GET /systemSettingsdevolviendo JSONP (Accept=application/javascript) fue eliminado
Future API changes¶
Please note that from 2.38 onwards several API endpoints slightly change their response root object to be in line with the majority of endpoints. The root object returned pre 2.38 will become the member named response of the root object returned by 2.38. Consumers can opt to either use /api/37/... to get the old behaviour or have to unpack to new response by doing <root>.response to resolve the old root from the 2.38 response. In case of error responses this also entails an HTTP status code change from 200 OK to 409 Conflict.
Los endpoints afectados son:
POST /api/completeDataSetRegistrationswithJSON/XML(only nonasyncaffected)POST /api/dataValueSetswithJSON/XML/ADX/CSV(only nonasyncaffected)POST /api/metadatawithJSON/XML/GML/CSV(only nonasyncaffected)POST /api/predictions(only nonasyncaffected)PUT /api/predictions(only nonasyncaffected)PUT /api/relationships/{id}PUT /api/users/{uid}withJSON/XML
Migrations (Chart and ReportTable)¶
Depending on the DHIS2 version you're updating from, you may face migration issues/errors related to the removal of ReportTable and Chart tables. The failure could be caused by tables that are still present in very old versions of DHIS2. Even though they are not in usage they might still be referenced. This will cause errors when the migration scripts try to remove ReportTable and Chart tables because of the constraints present in those legacy tables. More details related to this issue can be found at https://jira.dhis2.org/browse/DHIS2-12601
Once those problems are identified and confirmed, a few legacy tables need to be dropped before attempting the migration to DHIS2 2.37.
Below we list the SQL statements that need to be executed directly in your PostgreSQL instance. These SQL statements are applicable if your starting DHIS 2 version is between 2.24 and 2.31 (inclusive).
DROP TABLE IF EXISTS charttranslations CASCADE;
DROP TABLE IF EXISTS reporttabletranslations CASCADE;
DROP TABLE IF EXISTS dashboarditem_reporttables CASCADE;
DROP TABLE IF EXISTS dashboarditem_charts CASCADE;
Assuming the statements are successfully executed you will be able to try the upgrade again.
SMS Codes¶
During the upgrade process, the migration related to SMS codes might fail depending upon if database has invalid categoryoptioncomboid or not. The migration in question is named V2_37_46__Add_coc_fk_in_smscode.sql. If this occurs, you can resolve it using the SQL script provided below. More details can be found at https://dhis2.atlassian.net/browse/DHIS2-15169.
After applying the script, retry the upgrade process. This should resolve the issue and allow the upgrade to complete successfully.
Note: Please ensure you have a proper backup before executing any SQL scripts during the upgrade.
-- Set invalid cat option combos to default
update smscodes set optionid = (
select categoryoptioncomboid from categoryoptioncombo where name = 'default')
where optionid not in (
select distinct categoryoptioncomboid from categoryoptioncombo)
or optionid is null;