Updated add province uri migration to avoid duplicates
Added a cleanup migration for adding province URIs to addresses
Updated the export,json config to expose the province URI of addresses
Fixing errors after review
Updated CHANGELOG
Refactored and corrected migrations, changed the timestamps
refactoring cleanup migrations
Refactored the cleanup add province migrations
Updated changelog to ensure db-cleanup-service picks up the new jobs.
The data on werkingsgebieden was largely duplicated across two graphs the shared
graph and administrative unit graph. Some exceptions were that werkingsgebieden
with level "referentieregio" were only in the shared graph, whereas
werkingsgebieden for new municipalities that resulted from the 2025 mergers were
only in the administrative unit graph.
This moves all the werkingsgebieden and their corresponding data to the public
graph, resolving the duplication in the process. Furthermore, the `public` and
`organizations` producers are update to only look in the public graph for
locations.
These memberships can be edited by users via the related organisations
page. If this data is kept in the read-only shared graph this leads to
unexpected behaviour when users (try to) remove such a membership. More
specifically, as the user has no write acces to the graph the request will be
silently ignored and the "removed" data will simply reappear after saving the
form.
As part of the 2025 municipality mergers some NIS2019 codes were linked to their
NIS2025 counterparts using `skos:narrowMatch` or `skos:broadMatch`, instead of
`skos:exactMatch`. Consequently, the initial insertion of the NIS2025 codes did
not update the NIS code for the werkingsgebieden linking to these.
We do want to avoid inconsistencies popping up; i.e. bestuurseenheid
label gets upated, but that won't be reflected in the landing zone
since the information by the producers is not produced anymore,
potentially bringing very confusion situations
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This adds new time specialised governing bodies for the
new (current) legislature for Raad van bestuur and Algemene vergadering.
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This sets the end date for the existing Raad van bestuur and
Algemene vergadering governing bodies.
For new frontend functionality concerning local involvements a worship user
should be able to read the status for municipalities and provinces. This
migrations moves these triples to the shared graph such worship users have read
access. The status for municipalities and provinces cannot be changed by users
so no write access is needed.
The mandatarissen and leidinggevenden consumers were missing a date
formatting mapping that is making sure that the data we display to the
user is of the same date as the one shown in the original app. This
transcription was made by the reasoner and we forgot to include it in
the mapping configuration.
I also updated the timestamp of migrations that need to run again when
I'll re-deploy to QA and DEV. It will have no impact on the upcoming
PROD deploy.
and not only the ones coming from Loket. There is a risk that we delete
too much data here but if that would be the case, the data is
recuperable through the backups by looking at persons and worship
positions that were in OP but not in the worship services landing zone.
The consumer needs to dispatch data to two different graphs: the worship
services graph and the privacy graph, based on triple type and/or
property. The latest version of the consumer doesn't allow it to be done
in one consumer instance, hence de split into two consumers.
