- Added a migration to change (only for KboOrganisaties) all dates/strings for modified and startDate to dateTime according to comment in ticket
- Added a comment to remind to bump version of kbo-data-sync when the kbo-data-sync PR is merged.
- Added to changelog
The previously added migrations can create new aggregate location resources for
worship administrative units that have multiple locations as scope of
operation. While those migrations did insert a label for these new location
resources, the contained names are typically not sorted alphabetically as
`GROUP_CONCAT` does not provide guarantees on sorting.
This script allows to generate additional migrations to correct those labels.
Co-authored-by: @cecemel
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 service provides functionality to manage an organisation's scope of
operation. To this end it facilitates that each organisation can be linked with
exactly one location resources as scope of operation, internally creating and
linking the appropriate resources.
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.
