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.
