🆔FP: Mechanism to copy/select contact details of a person
Solution for persons with multiple positions
Status Feature Passport
| STATUS | OWNER | DATE |
|---|---|---|
In proposal | Sofie | 15/03/2022 |
In refinement - Design Research | Saska | 07/04/2022 |
In refinement - Technical Research/Feedback | Nordine | |
In development | Nordine | POC 14/04/2022 |
In QA/ Testing | ||
In Final state |
Analysis
Current state
Persons can have multiple positions in a Governing body (bestuursorgaan). They can have a position as a mandatary (mandataris) and as a board member (bestuurslid).
In the context of worship services, this is always the case; in the context of other administrative units, it is not always the case.
Problem - scenario's
A clear implementation plan exists to handle this: When end-users add a mandatary position for a person and fill out all the contact details, they have to type in the same contact details when they register the board member position for the same person.
When an address changes during a legislation, we have to change this manually in all the positions.
Why do we need a solution?
to speed up the data correction by 1-time input. We have agreed with the persons doing the data correction to only fill in the contact details of the active positions.
to prevent user mistakes (we might have unintended two slightly different addresses for one person)
extra functionality: change an address 1 time and change the same address everywhere for that person on an active position
🤩 Expectations
In this feature passport, we will tackle these expectations:
Main functionality
As a user I want to reuse an address if this already exist for that person so that I don't have to re-type or copy all of the contact details (contactgegevens).
Extra functionality
As a user I only want to change the existing contact details once (in case of a change in one or more fields) so I do not have to do the changes in other instances of the contact details.
🤔 Discussion points
1. Do we need to make changes in the datamodel?
Mandataries and board members (Mandatarissen en bestuursleden)
Private adresses are used (not public available):
In the context of worship services most of the addresses are private addresses because it involves volunteers.
In the context of associations private addresses might be used as well (to analyse later, when we start the module "companies & associations" (ondernemingen en verenigingen))
Adresses of organisations are used (public available):
In the context of other administrative units, the addresses of the administrative unit or governing body are used.
In the leidinggevenden databank and thus available in the 'leidinggevenden' databank of LLB.
Leidinggevenden databank application profile OSLO
In the context of companies, the address of the company will be used as well (to analyse later, when we start the module "companies & associations" (ondernemingen en verenigingen))
No address available:
It is not asked in the module 'mandatenbeheer' in LLB and thus not available in the public mandatendatabank of LLB.
mandatendatabank application profile OSLO
In the case of persons, it is logical that a contactpoint is connected to the position. We have no legal ground to ask or store the private addresses of persons.
According to the OP datamodel we have a contactpoint in the classes:
OSLO-Generiek::Agent
OSLO-Organisatie::Vestiging
OSLO-Bestuur::Bestuursorgaan (contactinfo is added to bestuursorgaan after discussions in a group meeting 27/4/2021, although it is inherited through agent-organisatie)
Representatief Orgaan (ERE)
AgentInPositie
OSLO-Leidinggevenden::Bestuursfunctie
2. How can we line up with 'Loket voor Lokale Besturen' (LLB)?
worship services
existing 'leidinggevendendatabank'
existing 'mandatendatabank'
3. If we create an extended solution, can it be re-used by LLB?
We should only create the extended solution if it can be re-use in LLB.
4. Do we have to make a distinction between personal e-mail adresses and business e-mail adresses?
Talked to Veronique about this. No, we are going to make it unnecessary complicated. Endusers probably will not use it the right way.
5. Is it a problem that part of the entries have been copied already?
🤔 Use cases to think about
Saska: What if the contact details for position A, B and C are the same, but you just want to change the details of B? Will that also still be possible or will the details of all three positions change automatically?
Claire: if they share the same address, it'll change everywhere, that could be an issue indeed
Sofie: What if the address is not changed, but a part of the department of for example a municipality moves to another existing address, the other part stays in the same address, the address needs to be changed as well.
Saska: Also another thing I just thought of: within OP I assume we can see the addresses across organisations, but when we do this in loket i'm assuming you will only be able to copy addresses already used for that organisation, not for positions someone has had in a different organisation right?
Claire: Yes indeed, good point ! It should be fine because in Loket, the user will have access to the addresses within its organization and will only be able to copy paste it to that same organization.
Do we also have to change the addresses of non-active positions?
Dries: what if we have an outdated address linked to a previous - inactive position. We do not suggest to use that one? What if a person has both an old outdated address linked to an inactive postion and an actual address linked to an active postion?
Solution
Design
Problem to solve:
A user can have multiple positions with the contact details. Users will have to type the same details multiple times. This results in * more work for the user * data problems if user inputs is wrong
Solution
A user can re-use contact details already in use for that person
Impacted flows/screens
During position creation
During editing of contact information on the position detail page
During the editing of contact information on the Contactgegevens (previously known as personal information) page [THIS WILL NOT BE IMPLEMENTED FOR NOW]
Mock-ups
Position creation
We change the contact information card previously used by a contact information table. The table contains a column for:
Address [Adres]
Flat number [Bus]
County [Provincie]
E-mail
Primary telephone number [Primair telefoonnummer]
Secondary telephone number [Secondary telefoonnummer]
Select option [Selecteer]
When the user creates a position, they are prompted with all the contact details already in use for that person. The user can then select, by ticking the checkbox, if they want to use already existing details, or if they want to create new contact details, they will be prompted with a modal to do so.
If we user fills in new contact details, the checkbox gets automatically selected for them.
We only show contact details in use in ACTIVE positions for that person.
Editing - position detail page
Similarly to the creation page, we will change the contact details card into a table.
The only difference with the table in the position creation page is that in this scenario, the user is allowed to edit the previously input fields.
This is in case the user sees a mistake, like a typo, rather than needs to update the already existing details.
When the user fixes the typo, that change will be reflected in all the places this contact data is used - we tell this to the user using a (i) hint within the journey.
The correcting of data will happen through a modal:
If the user changes the contact details for a position, and the old data is used for another position, the user goes to a second step in this journey:
Here, the user sees a table of all the positions using those old contact details, asking if they want to update those [old] contact details into the new ones they have updated in the previous step.
If the user leaves the journey at this stage, the contact information updated in the previous step will still be saved.
Editing - Contactgegevens (previously known as Personal Information) page
DO NOT IMPLEMENT
This works the same way as the other editing journey, apart from the fact that all currently active positions are available in one page. This makes step 2 of the previous journey redundant.
The user needs to go through all the contact information tables one by one to check the row that applies for that position.
If the user creates a new row of information, that row should be automatically available in the other tables for the user to select
Technical
Scenario 1: make a deep copy of contact details for each active positions. Depending on how it will be designed, user would have to click on (as proposed by Saska Pallayova during the BRM) a checkbox "Use as the default contact details" when editing, which will automatically copy the data on each position's details. The user then needs to press "save" in order to have the changes applied. It could also be a select box. This is the simplest solution in my opinion, as we do a deep copy. Each time the user does a change to the default contact detail, he must click again on the checkbox (because we don't store it, if we store it we need to add a new field to the model)
Scenario 2: make a shallow copy (only the uri reference of the address for example) of the contact details. This seems feasible and will be very similar to scenario 1, but we might hit to some issue during the implementation (we also might not). For example, what if the current active position used as the default becomes inactive? What if user delete the contact details data for the default ? We will have an empty resource, which in theory should be deleted (see OP-1005).
Both solution seems to be ok, but the least difficult seems to be scenario 1. This is mostly "gut" feeling, as I think everytime something has to be kept in sync, it produces unexpected problem at some point (scenario 2). It could be very ok to do scenario 2, but it could be a bit more risky.
Last updated
