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.
Re-enable editing contact data in OP as the CLB app editing functionality was
disable due to data flow issues. This sets the relevant frontend feature flag
such that it allows editing the contact data for all organizations
classifications agains.
When deploying make sure this environment variable is **not** overwritten in the
environment's `docker-compose.override.yml`.
The most recent merge commit from master to branch contained error were a
removed line was reinserted at a wrong place with an incorrect indentation .his
causes (some) drc commands to fail with an error
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.
This service will be used to insert and delete triples for the
`org:hasSubOrganization` and `org:linkedTo` predicates when appropriated
memberships have been added or deleted to the triplestore.
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.
The municipality of Borsbeek will merge with the municipality Antwerp as of
01-01-2025. This will result in a new district Borsbeek part of municipality
Antwerp.
This migration adds that new district such that a URI is assigned to it and its
governing bodies are created. The information available at this time is limited
its (legal) name. Other core data, such as identifiers, and further information
such as site addresses will be added later by business.
