🆔FP: Split worship services from other administrative units
To comment on a FP:
Date, name: comment
Status Feature Passport
| STATUS | OWNER | DATE |
|---|---|---|
In proposal | Sofie | ... + 27/11/2022 |
In refinement - Design Research | ||
In refinement - Technical Research/Feedback | ||
In development | ||
In QA/ Testing | ||
In Final state |
EPIC = OP-1762: Split worship services from other administrative units
Analysis
This part of the feature passport is owned by the analyst
Current state
All administrative units and positions are displayed together in the front-end in the modules 'bestuurseenheden' and 'personen'.
worship services
central worship services
gemeenten
OCMW
districten
provincies
6 administrative units are already in OP (see bulleted list above).
11 other administrative units will be added as soon as possible.
1. Type of positions
We store/show different kinds of positions in OP
Religious mandates
Political mandates
'Leidinggevenden'
Later we might store/show
Other positions in an administrative unit
Position in companies (only when this position is related to the political mandate)
Positions associations (only when this position is related to the political mandate)
We will not store/show
Data from private person (f.e. citizens that file a complaint) (we are not going to save them)
2. Module 'bestuurseenheden'
Positions and the persons active in these positions are shown in the module 'bestuurseenheden'.
2.1. via menu Bestuursorganen (governing body in time)
Printscreen link: https://organisaties.abb.lblod.info/bestuurseenheden/e2eea8a352821c9c1f1827f1cfde9f24/bestuursorganen
Printscreen link: https://organisaties.abb.lblod.info/bestuurseenheden/e2eea8a352821c9c1f1827f1cfde9f24/bestuursorganen/76029a4c8454a29a3a9b26c818199443
2.2. via menu Bedienaren (ministers) = only for worship services
Printscreen link: https://organisaties.abb.lblod.info/bestuurseenheden/e2eea8a352821c9c1f1827f1cfde9f24/bedienaren
Data with links:
Voornaam and Achternaam are linked to the module 'Personen > Contactgegevens'
Position (=Rol or Mandaat) is linked to the module 'Personen > Positie'
Other administrative units (gemeente, OCMW and provincie) have an extra menu-item 'Leidinggevenden'. These positions are not applicable to worship services.
3. Module 'Personen'
Positions and the persons active in these positions are shown in the module 'Personen'.
2.1. via menu Contactgegevens (only active positions)
Printscreen link: https://organisaties.abb.lblod.info/personen/6241B0727B850F1C3687AA8E/contactgegevens
2.2. via menu Posities (all positions of that person, active and non active)
Printscreen link: https://organisaties.abb.lblod.info/personen/6241B0727B850F1C3687AA8E/posities
Problems
Why do we want to make the separation?
1. Different types of positions are shown in one list
In general it is more safe (legal and ethical reasoning behind this) to not show religious mandates toghether with political or any other position.
We have to show the religious mandates in a separate list, separated from the other positions.
In the printscreen below (with dummy data) you can see that all type of positions of one person are shown. (F.e. John Adam has both political as religious mandates)
Yellow marker = political mandates
red marker = religious mandates
Printscreen link: https://organisaties.abb.lblod.info/personen?given_name=john
Another example: https://organisaties.abb.vlaanderen.be/personen?family_name=Billens&given_name=Samuel&status=false
This rule might be extended to other types of mandates. F.e. don't show leidinggevenden and mandates in one list.
2. Data about religion is very sensitive
The business will feel much more comfortable if all the data concerning religion is only available for persons working with these data. (also see FP: Roles and Rights)
The data concerning the administrative unit is public information. But the data of the persons is not.
🤩 Expectations
1. Separate religious mandates from other types of positions
We have to show the religious mandates in a separate list, separated from the other positions.
Make it possible to split other types of positions as well in the future
political mandates
leidinggevenden
all the other positions that don't belong to religion or politics
If needed we should be able via SPARQL queries to have a report (there has been no request for this, but it might be requested in the future)
of all the persons that have a combination of religious, political or other positions
of a specific person with all his/her positions no matter what type
2. User experience
The end-user can easily switch between worship services and other administrative units and vice versa.
The end-user doesn't have to login multiple times.
The end-user should feel that he/she is working in the same application.
🕵️♂️ Use Cases
A person can have
one position in one administrative unit
multiple positions of the same type in the same administrative unit
(f.e. bestuurlid + voorzitter in a worship service)
multiple positions of a different type in the same administrative unit
(f.e. bedienaar + bestuurslid in a worship service)
the same position in different administrative units
(f.e. algemeen directeur in gemeente + algemeen directeur in OCMW)
multiple positions of the same type in different administrative units
(f.e. bestuurslid in worship service A + bestuurslid in worship service B)
multiple positions of a different type in different administrative units
(f.e. bestuurslid in a worship service + algemeen directeur in gemeente)
🤔 Discussion points
Does this split have an impact on other developed functionalities in OP?
Does this split have any impact on developed items in Loket? Do we need to do this split before the view of OP is developed in Loket?
Do we split both modules, 'Bestuurseenheden' and 'Personen'? Or do we only split 'Personen'?
Before forming a plan, take into account the following Feature Passports
Can we extend the rule of separation of positions easily? For example: don't show leidinggevenden and mandates in one list.
Which URI strategy?:
A person can have multiple person URI's linked to different mandates (see table)
A person has one person URI linked to different mandatess
| Persons URI | Position | Positions URI |
|---|---|---|
URI_A | religous mandate | POS_0 |
URI_B | political mandate 1 | POS_1 |
URI_B | political mandate 2 | POS_2 |
URI_C | private person | POS_3 |
What are the possible risks?
What are unknown areas?
What are the possible implications/consequences in
user experience
speed
maintenance
security
deployments and re-indexing
Solution
The next two parts of the FP can [sometimes] be worked on simultaneously
Design
This part of the feature passport is owned by the designer
User research
[If there is any user research preceding the wireframe mock-up stage, it needs to be documented here]
Mock-ups
[link to figma mockups + any explanation or extra documentation]
Technical
This part of the feature passport is owned by the technical team
[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]
After the designer and/or the technical team finish their task, a meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.
Last updated
