Index municipality names as keywords instead of as plain text. This prevents
them from being split at word separators. Thereby avoiding that searches for a
municipality name, as used by the frontend's municipality filter, return
organisations whose municipality is a partial match.
For example, previously the results when searching for "Puurs" also included the
organisations located in "Sint-Amands-Puurs". The latter was tokenized into
three terms, therefore also matching plain "Puurs". By treating the municipality
name as keyword this split non longer happens.
The default behaviour should clean any number that can be cleaned BUT
let the other numbers flow without any modification. The previous
behaviour I'm fixing here was to NOT let them flow if they were not in a
"cleanable" format.
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.
The worship service St.-Amandus was not included as `orginalOrganization` in the
merger change event somehow. As a result it was not listed as involved
organisation in the change event details. Furthermore, its status was not
correctly updated to "Not active".
- Migrations to create the necessary merger change events that represent the
merger of several police zones into three new ones
- Migration to update the status of the merged police zones to not active
When new organisations were added for some merged municipalities (see PR #442)
their `org:hasSubOrganization` link with the province was inserted in to the
`<http://mu.semte.ch/graphs/administrative-unit>` graph instead of the
`<http://mu.semte.ch/graphs/shared>`.
Consequently, when logged in as a worship user and either of these
municipalities were selected in a form, the corresponding province was not
automatically filled in. This is due to the fact that worship users cannot read
from the `administrative-unit` graph.
This migration moves the appropriate `org:hasSubOrganization` triples to the
correct graph such that the behaviour for worship and non-worship users is the
same again.
This migration regenerates the `locn:fullAddress` triples for addresses in a
municipality involved in a merger. In essences this migration updates the
`locn:fullAddress` triple for each address changed by the migrations in the
previous commit.
Notes
- The migration is split over two queries, one for addresses without a box
number and one for addresses with a box number. This avoids complicating the
query with conditional logic at the cost of code duplication in the queries.
- In the existing full address triples two different notations are used to
separate the box and building number. OP currently separates them simply by a
space, which is what this migration matches for. But some historical data uses
a dash "-" to separate building and box number. Consequently, this migration
might match more address resources than strictly updated for the municipality
merges.
This migration updates the municipality name in the addresses for all
organisations located in a municipality whose name changes due to the 2025
municipality mergers.
As part of the 2025 municipality mergers Zwijndrecht will merge with Beveren and
Kruibeke into Beveveren-Kruibeke-Zwijndrecht. Additionally this means that
Zwijndrecht changes province from Antwerp to East Flanders.
This migration updates the province for each organisation with an address in
Zwijndrecht to East Flanders.
