v1.5.1: Release notes
OpenCRVS v1.5.1 is a patch release which includes a hotfix to the previous OpenCRVS v1.5.0 release. It is to be used in conjunction with a forked country configuration release v1.5.1
OpenCRVS v1.5.1 is a patch release which includes a hotfix to the previous OpenCRVS v1.5.0 release. It is to be used in conjunction with a forked country configuration release v1.5.1
When viewing a record, child national id or any other identifiers are fetched from backend if available. This enables any external identifiers (e.g. national id) added during the registration of a record to be shown when viewing it
Home screen application’s name and icons are to be configured from country configuration package as manifest.json and app icon files are moved from core to country config (check opencrvs-countryconfig/src/client-static folder)
On slow connections or in rare corner cases, it was possible that the same record got saved to the database twice. This was caused by a bug in how the unique technical identifier we generate were stored as FHIR. The backend now ensures every record is submitted only once.
Fixed an issue where address line fields (e.g., address line 1, address line 2, etc.) were not being updated correctly when a user attempted to update a record's event location, such as place of birth or place of death.
Handle label params used in form inputs when rendering in review section view
Fix probable migration issues for countries migrating from 1.2
When a declaration(birth/death) is created the event location information was not being parsed to ElasticSearch which caused the Advanced search feature to not work when searching for records by event location.
When any user's role was updated, incorrect role was shown for that user's actions in the history section of a declaration's record audit page.
Registration agent was unable to download declarations that were previously corrected by registrar.
When a user updates a marriage declaration editing the signature of the bride, groom, witness one or witness two, handle the changed value of the signature properly.
The internal function we used to check if all the location references listed in the encounter are included in the bundle had incorrect logic which resulted in location details missing in ElasticSearch which broke Advanced search.