A number of APBs were accidentally `org:linkedTo` all municipalities in
municipality and an APB for which:
- the APB is linked to more than 1 municipality; and
- the municipality does not match that of the APB's primary site.
The first condition avoids we remove `org:linkedTo` triples for APBs that were
created by the users, as these are only linked with a single municipality.
Originally the starting dates for the new governing bodies for the new
legislature was set to `2025-01-01` for all relevant municipalities, OCMWs,
districts, and provinces.
These migrations change that to more correct starting dates:
* For organisations that are **not** involved in mergers the new starting data
is `2024-12-02`, the first day installation meetings are allowed[1].
* For organisations that are involved in mergers the new starting date is
`2025-01-01`, the first work day of the new year on which the mergers take
effect. Note: this migration assumes there are no other start dates on
`2025-01-01`, so the migrations have to be run in the specified order.
[1] https://www.vlaanderen.be/lokaal-bestuur/organisatie-en-werking/gemeenteraad/installatie
These migrations add the contact data from CLB production that was modified in
that app during the time it was available. These migrations perform the
following actions, in the specified order:
1. Delete all contact data for the 8 modified sites
2. Import the data extracted from CLB production for the relevant organisations
Done in separate migrations for worship and non-worship organisations.
3. Correct a phone number literal that contained spaces for some reason
OP will take over the editing of contact data again. This removes the CLB
consumer from OP altogether such that it cannot be accidentally be reactivated.
Add the migrations to create the necessary memberships for the newly added
municipalities and OCMWs. These new organizations were added as part of a hotfix
after the memberships were added to development. Consequently, the migrations
inserting these organizations are performed **after** the migrations introducing
membership data. Therefore, we need to add some additional migrations
specifically for these new organizations.
This migration removes a bunch of memberships which `organization` assignment is
not valid. These memberships were most likely created by (automated) testing
while the frontend did not correctly enforce the correct direction.
When removing memberships some `org:hasSubOrganization` or `org:linkedTo`
triples may remain in the triplestore. These migrations add jobs to delete such triples.
Triples for the predicates `org:hasSubgOrganization` and `org:linkedTo` are
produced by OP for other apps to consume. Therefore, they should not be deleted.
These two migrations were accidentally placed in the `migrations` folder instead
of the appropriate `2024` subfolder. These migrations have already been executed
on all environments.
For each of the governing bodies created by the migrations in the previous
commit, now add the corresponding mandates and functions.
Within a organisation some governing bodies share the same mandates. For
example, for municipalities the governing body "Burgemeester" and "College van
burgemeester en schepen" both refer to the SAME instance of mandates for
"Burgemeester" and "Aangewezen burgemeester".
To achieve this the some migrations contain a second `INSERT` clause in which
the other governing body that contains the necessary mandates is selected to be
able to determine the correct mandate URI. This only works on two conditions:
1. Migrations that depend on each must be executed in the correct order. For
example, the migration inserting the mandates for "College van burgemeester
en schepen" must be executed after that for "Burgemeester". The former will
reuse mandates created by the latter.
2. The UUID for the shared mandates is calculated in exactly the same way in
migrations that depend on each other.
The merged OCMWs as imported in #442 were lacking some governing bodies that are
used to relation funcations to. These migration add the missing governing
bodies for these OCMWs.
These migrations create the necessary time specialised governing bodies for
municipalities, OCMWs, district and provinces for the next legislature.
The migrations work by creating a new time specialisation, with an appropriate
starting date, for each abstract governing body associated with an active
organisation. For municipalities and OCMWs some instances are explicitly
filtered, these are municipalities (OCMWs) that will be merged with another one
as of 01-01-2025 and therefore will become inactive. The listed
municipalities (OCMWs) are extracted from data provided by business.
