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.
