There is a 'double' instance of CKB Deinze in the database. One is active, and the other is inactive. This confuses systems, and it doesn't make sense that active organizations are linked (almost managed) by an inactive organization.
* Insert suborganization(s) belonging to non-active org to the active one
* Insert new membership belonging to the suborganization(s) and active org
* Delete memberships for non-active org
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.
The entries about the public producer changes accidentally ended up in the
v1.31.0 section but were not actually part of this release. This moves them back
to the unreleased section so they are correctly included in the next release.
A migration to flush the landing zones of consumers for bits of the data. Since this data is not actively maintained anymore by the producers, this might lead to obsolete information and confusion situations at the consumer side. Context: deploy story DL-6552
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
