We do want to avoid inconsistencies popping up; i.e. bestuurseenheid
label gets upated, but that won't be reflected in the landing zone
since the information by the producers is not produced anymore,
potentially bringing very confusion situations
`MaxConstructTriples` needs to bumped to the same value as `ResultSetMaxRows`
since `virtuoso` will check the value of the former variable first. By setting it
to 10000, we were severely limiting the number of triples that can be constructed.
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This adds new time specialised governing bodies for the
new (current) legislature for Raad van bestuur and Algemene vergadering.
The governing bodies for an AGB have the same legislature as the corresponding
municipality. This sets the end date for the existing Raad van bestuur and
Algemene vergadering governing bodies.
For new frontend functionality concerning local involvements a worship user
should be able to read the status for municipalities and provinces. This
migrations moves these triples to the shared graph such worship users have read
access. The status for municipalities and provinces cannot be changed by users
so no write access is needed.
The mandatarissen and leidinggevenden consumers were missing a date
formatting mapping that is making sure that the data we display to the
user is of the same date as the one shown in the original app. This
transcription was made by the reasoner and we forgot to include it in
the mapping configuration.
I also updated the timestamp of migrations that need to run again when
I'll re-deploy to QA and DEV. It will have no impact on the upcoming
PROD deploy.
Considering the time it takes to do a full re-index the speed benefit of the
development-specific configuration is limited. To the point that it does not
seem to outweigh the added complexity of maintaining two configurations and the
added chance of errors that brings.
The indexes for the municipality and province of a position's organisation are
not used in the app. Removing them to decrease the time required to index data.
This makes diff'ing the dev and prod configurations for the `search` service
slightly more readable.
- use same order of eager index entries with prod confiuration
- remove an extra normalizer setting in the dev config
- remove duplicate person id index
- correct property name in identifier mappings
- add missing `first_name_used` mappings
- order properties and mappings consistently across file
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.
