🆔Related organisations: relationship types
Improvement of existing related organisation page by adding relationship types
To comment on a FP:
Date, name: comment
Status Feature Passport
| STATUS | OWNER | DATE |
|---|---|---|
In proposal | Sofie | 12/04/203 + 13/04/2023 |
In refinement - Design Research | GS26 - sprint 3 | |
In refinement - Technical Research/Feedback | Claire | 26/07/2023 |
In development | ||
In QA/ Testing | ||
In Final state |
Epic = OP-2272: Related organisations: relationship types
Analysis
This part of the feature passport is owned by the analyst
Versions of related organisations
Related organisations were shown in the MVP version as a list in a card within the page 'Kerngegevens'.
Related organisations as a separate menu item = [OK] Related Organisations
This FP = Improved related organisations by adding relationship types in the table
Current state
1. Existing relations regarding worship services
1.1. A worship service can have a link to
1 representative body
1 central worship service
Links to local governments can be viewed in 'Betrokken lokale besturen'.
1.2. A central worship service can have a link to
1 representative body
multiple worship services
Links to local governments can be viewed in 'Betrokken lokale besturen'.
1.3. A representative body can have links to
multiple central worship services
12/04/2023: Yassin Boullauazan do you need other types of relationships for worship services in the future?
25/4: Sofie M, to my knowledge there is no request to add new organization relations.
2. Existing or future relations regarding other administrative units
2.1. A Municipality (gemeente) has a link to
1 OCMW
1 province
9 districts (= only applicable for gemeente Antwerpen)
2.2. An OCMW has a link to
1 municipality
1 province
2.3. A District (only applicable in Antwerpen) has a link to
1 municipality
1 province
1 OCMW
2.4. A Province has a link to
multiple municipalities
multiple OCMW's
2.4. An AGB has a
geographical relation to 1 municipality
geographical relation to 1 province
geographical relation to 1 district (only applicable in Antwerpen)
was founded by relation to 1 municipality
2.5. An APB has a
geographical relation to 1 municipality
geographical relation to 1 province
geographical relation to 1 district (only applicable in Antwerpen)
was founded by relation to 1 province
Define relationship types
see ticket: OP-2300: Meeting with Organisatieregister Wegwijs about the type of relationships they use (Organisatieregister Wegwijs)
List of relationship types used in Wegwijs:
This was discussed in a meeting with Boris, Evelyn, Frank on friday 7/7/2023 'OrganisatiePortaal: afstemmen rond modellering'
OP will not copy all the relationship types of Organisatieregister
Agree on which type of relationship we will use.
OR: Organisatieregister will map to whatever relationships we create, naming can be different
Map existing relationships in OP and OR.
OR: Will be done later
How will we handle/agree on a new type of relationship needed in the future?
OR: We can add relationships as we want, we let them know when we save new relationship types.
Relationship types we need in OP
| Relationship type | Reverse relationship type |
|---|---|
ligt geografisch in (= is geographically located in) | omvat geografisch (= includes geographically) |
is oprichter van (= is founder of) | werd opgericht door (= was founded by) |
participeert in (= participates in) | heeft als participanten (= has as participants) |
heeft een relatie met (= has a relation with) | heeft een relatie met (= has a relation with) |
New relationship types might be needed in the future.
to analyse (relationships within the model)
= extra relationship types or mapping on existing one.
heeft suborganisatie
is lid van
is geassocieerd met
Missing information
✅ Missing relationship in current administrative units = OP-2390
Provinces: Province Antwerp also has a geographical link to the 9 districts of Antwerp. (see ticket OP-2390: Related organisations: add geographical relationship with district in Antwerp (province) = status Getest op TEST
FYI: This ticket is linked to another epic OP-1797 since it is not really part of this improvement version.
🐛 Bug
The table is sorted by column Organisation by default, but you can not change the sorting in any of the columns.
Example: province Antwerpen https://organisaties.abb.vlaanderen.be/bestuurseenheden/bd74ee38a4b1e296821a11729c1f704cf439576c7ab2c910c95b067cf183d923/gerelateerde-organisaties
Sofie 26/07/2023: This ticket is a duplicate of OP-2439: Overview Related organisations - unable to sort columns. Thx for noticing Claire!
🕵️♂️ Possible improvements
1. On the related organisation page we have (in some cases) different layouts to show relationships
= OP-2580 > status VERWIJDERD
They both have the title 'Heeft relatie met' (has relationship with). This might be confusing to end-users. We should add all relationship types in a table.
Example: Related organisations in the municipality Antwerpen: https://organisaties.abb.vlaanderen.be/bestuurseenheden/670db1d66c0de3b931962e1044033ccfa9d6e3023aa9828a5f252c3bc69bd32c/gerelateerde-organisaties
Relationships in cards
Relationships in table
💡 TO DO: Show all the relationships in one table
Possible extension > Question for Boris: Can we put the hierarchy of location, which is always derived information, in a card or in a separate table and give it the title 'hierarchy'? Most of the time this data isn't linked to an organisation (country, gewest, regio, subregio, bestuurlijk arrondisement).
Answer (Boris):
Yes, this is possible. For each location we know which locations are a "parent" locations and which ones are "children". For each of these locations we also have the type/level. e.g. province/commune/...
UX/UI question might be whether all children should be displayed at once or not. Since these can be a lot (e.g. for a gewest or country) , maybe some filtering should be foreseen.
[Answer by Saska Pallayova: agreed this is something to discuss -- it did come to light in jira and is being discussed there: https://binnenland.atlassian.net/browse/OP-2609 ]
We can use the outcome of this notebook. We should keep in mind that the data should be updated every now and then - the frequency of NIS/LAU and other updates is low though.
fwiw: an example of browser for a complex medical hierarchy - i think we can keep it simpler though.: https://browser.ihtsdotools.org/?perspective=full&conceptId1=840539006&edition=MAIN/SNOMEDCT-BE/2023-05-15&release=&languages=en
01/08/2023 summary of meeting with Saska: Saska will create a design for the extension (OP-2609), taking into account the remarks of Boris.
The general idea of Saska is to show the geographical relations in a card on the page 'Kerngegevens'. We already show the region on that page.
Most of the geographical area's are no organisations in OP except for
province
municipality
district
If an organisation has a relationship with one of these three types of administrative units we will also show the on the page 'Gerelateerde Organisaties' (Related organisations).
Detailed information is available in the ticket (OP-2609).
Ticket to create new card (OP-2610).
28/08/2023 summary of meeting with Saska, Claire, Boris and Sofie:
It's been pointed out, and clear now, that the 'werkingsgebied' is used to show geographic information and not the primary address.
We have 'werkingsgebied' for municipalities, OCMW, district and province, so we can add geographic information in those administrative units.
For the other administrative units we need to create a field 'werkingsgebied' (OP-2672)so we can use that data to show the geographcal information.
We will no longer show all the relationships in one table. Instead we use tabs (see appuniversum) on the related organisations page and show
the general relationships in a table on the first tab called 'Algemene relaties'
the geographical relationships in a table on the second tab called 'Geografische relaties'
Saska will create a new design (OP-2671).
Ticket OP-2580: Related organisations: Show all relationships in one table (got status VERWIJDERD)
2. In the table we have different type of relationships but the type isn't mentioned yet
= OP-2581
💡 TO DO: add an extra column to the table to show the relationship type
Order of columns in the table: (to check with Saska)
Columns:
Type relatie (= predefined list, result of OP-2300 analysis) = default sorting
ligt geografisch in <> omvat geografisch (see question for Boris: for now we will take the general relationship type 'heeft relatie met')
is oprichter van <> werd opgericht door
participeert in <> heeft als participanten
heeft een relatie met <> heeft een relatie met
Type organisatie (= type of organisation)
Organisatie (= name of the organisation)
Status (= status of the organisation)
Example for Antwerpen (Gemeente) https://organisaties.abb.vlaanderen.be/bestuurseenheden/670db1d66c0de3b931962e1044033ccfa9d6e3023aa9828a5f252c3bc69bd32c/gerelateerde-organisaties
| Type relatie | Type organisatie | Organisatie | Status |
|---|---|---|---|
ligt geografisch in | Provincie | Actief | |
heeft een relatie met | OCMW | Actief | |
omvat geografisch | District | Actief | |
omvat geografisch | District | Actief | |
... all districts | all districts | all districts | all districts |
26/07/23, Claire Lovisa : To Sofie M, it looks like ligt geografisch in <> omvat geografisch and heeft een relatie met <> heeft een relatie met are not implemented yet. We use is sub organization of <> has sub organizations (links between AGB/municipality, Municipality/Province, OCMW/Province, EB/CB) as well as associated organizations <> is associated with (links between APB/Gemeente, CB/RO, Municipality/OCMW, EB/RO).
Is the goal to replace our current model by a new one ? If so, we have to be extra careful, with the sync to other apps, to make sure it'll not break other applications if we update it.
✅ 3. Page with lots of results take long to load
The results get displayed in one table without pagination. At the moment this is only a problem with the provinces. (example: 142 rows in table province Antwerpen: https://organisaties.abb.lblod.info/bestuurseenheden/bd74ee38a4b1e296821a11729c1f704cf439576c7ab2c910c95b067cf183d923/gerelateerde-organisaties)
As we onboard more administrative units this problem get bigger in the provinces table and will also probably occur with municipalities.
💡 TO DO:
✅ OP-2582 = Can we add pagination? This is also suggested in bug ticket OP-2440: Overview Related organisations - for some entries the status isn't shown
26/07/23, Claire Lovisa this might not be easy because we are going to mix multiple relation types in the table, not just one type as it's usually done. We'll see while implementing how hard it is.
✅ OP-2583 = Can we show by default only the active organisations? Use a toggle button to also show the non-active organisations.
see toggle button in module 'Personen'
Toggle in related organisations:
Toggle on shows only organisations with status ‘Actief’. (= Default state when page opens)
Toggle off shows all organisations regardless the status.
4. Can we add a filter to filter on type of relationship?
In the future?
26/07/23, Claire Lovisa : Yes
Discussed with Saska on 01/08/2023
OP-2608: Add filter 'type relatie'
Default filter = none
If possible: Dropdown options in the filter depend on the type of relationships that are used in the table. So if the type of relationship is not present in the table it should not be visible as an option in the dropdown.
Saska will create a design for this (OP-2609)
🤩 Expectations
Solve current problems:
Sorting does not work in the existing table
Show all relationships in one table
Pages with lots of results take long to load
add pagination
add a toggle button to hide non-active organisations
Add more knowledge:
Add the type of relationship to the table
🤔 Discussion points
Some questions were mentioned in the problems/improvements section.
If a relationship was created/changed in one organisation, the relationship is automatically captured in the related organisation?
Do we need to scope some problems/tickets or can we do this in one growthspurt?
26/07/23, Claire Lovisa : 1. Yes 2. It depends whether we need to change the entire existing model or not
04/08/23 Boris De Vloed
Separation of geographic relations and other relations is a good thing, as they are logically distinct as well.
The location hierarchy is in fact a hierarchy of organizations based on their werkingsgebied (and the geographic relations between those working areas)
The other relations are some kind of membership, with a specific type/role which can be put in a codelist and extended if needed (without impacting the model)
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.]
Bestuurseenheid > heeft > Werkingsgebied
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
