Add migrations to set the initial scope of operation for worship administrative
units. These migrations work in several steps:
1. Extract the necessary relations between worship administrative units and
locations based on the rules provided by business and insert this data in a
temporary graph.
2. For worship administrative units related to only a single location. Simply
add the triple setting that location as its scope of operation.
3. For worship administrative units related to multiple locations. Create new
location resources that aggregates all locations linked to a single worship
administrative unit and set this new location resource as scope of operation.
4. Clear the temporary graph.
Due to the restriction that an organisation can have only 1
location (nl. werkingsgebied) we need to create ad-hoc locations containing
multiple locations. As such enforcing that a location can only be contained in a
single other location is too restrictive. For example, this would prevent the
same municipality location to be within two (or more) different locations for
different organisations.
This organisation was removed from OP as it is officially not an administrative
unit. But it needs to be recreated to allow them to finalise subsidies via the
subsidie app.
As the resources has to be created with the same URI as before we re-add it
using a migrations instead of creating it manually via the frontend.
Putting the optional clause within the graph clause causes to query causes,
using DEV data, some organisations to be missed by the query. Turning the order
around resolves this without losing any organisations, tested with DEV and PROD data.
All resources with type `besluit:Bestuurseenheid` also have `org:Organization`
as type. Including both types in the queries leads to some organisations,
specifically municipalities in the `shared` graph, being included twice in the
results. Once with all data and once without label etc. This leads to the
results of both queries being incorrectly combined and having entries in the
final result without label.
This includes an organisation's URI in the response from the resource
service. This allows to easily get the URI for an organisation without having to
determine it based to UUID and classification and/or explicitly querying the
triplestore.
This is mostly a convenience for developers, but can be leveraged to add a link
to Centrale Vindplaats in the frontend.
As part of the 2025 municipality mergers, three municipalities kept their URI
but were renamed. This updates the labels for their scope of
operation (nl. werkingsgebied) locations accordingly. This way the label of the
location resources matches the name of the municipality administrative unit.
Add cleanup jobs to automatically insert and delete `org:hasSubOrganization`
relations between provinces and municipalities. These memberships were moved to
the `shared` graph causing the existing cleanup jobs to no longer work for them.
The frontend relies on the memberships relating municipalities and province to
- automatically select the appropriate province given a municipality; and
- limit the municipality options to those in a given province.
This kind of functionality is used in both the worship and non-worship module so
the data should be readable by users with either roles. This moves the
appropriate data the `shared` graph, which can be read by all authenticated
users. Thereby fixing that that functionality was broken for users with the
worship role.
* Added migration for Kabinet Crevits
Note:
`<http://mu.semte.ch/graphs/shared>` is only needed when data needs to
be availible to worship and non-worship users
* Update CHANGELOG.md
datafix: update status of kerkfabriek weelde to non-active
datafix: delete change event and update status to active for protesta…
datafix: update date of change event for islamic assocations
The `shared` graph still contains some location triples introduced as part of
the municipality mergers. They were overlooked by the original cleanup
migrations because the `prov:Location` and `ext:werkingsgebiedNiveau` triples
were located in the `administrative-unit` graph, causing the `WHERE` clause to
not match these triples.
The initial version of the migration, incorrectly, inserted the triples linking
municipality and province locations in the administrative unit graph. This
corrects that behaviour putting the triples in the public graph along with all
location data.
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.
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.
