🆔FP: contextual dropdown lists worship services

To comment on a FP:

Date, name: comment

Status Feature Passport

STATUSOWNERDATE

In proposal

Sofie Yassin

25/03/2022 + 31/03/2022 + 01/04/2022

In refinement - Design Research

No design needed for the filters. For new and edit we will need a design flow.

In refinement - Technical Research/Feedback

Claire (after discussion with Sofie)

04/04/2022

In development

In QA/ Testing

In Final state

Analysis

Current state

At the moment all possible options in the dropdown lists are shown and do not take into account the context in which the drop-down list is used. Sometimes a subset is required.

Dropdown lists are used in:

We’ve talked about this in the past, but it wasn’t a priority at that time, but we can no longer postpone this.

Problems

Impossible combinations are possible, for example:

  • Add a person: Central worship services can not have a 'bedienaar' https://binnenland.atlassian.net/browse/OP-1212 (the bug is solved in another way)

  • Filter: not every 'Soort eredienst' has a central worship service.

  • Change events: The list of change events for central worship services is a subset of the list of worship services.

Why do we need this?

  • We avoid end-user making impossible combinations while filtering or creating/editing new items.

  • We avoid end-user making mistakes.

  • We make it easier for the end-user by only showing the possible number of choices

    Some dropdown lists will become smaller.

  • Impossible combinations result in wrong data and wrong data reports.

  • For the moment, only the options for worship services are in the dropdown lists. We will have more options as more administrative units will be added.

Overview dropdown lists

1. Type of worship service (Soort eredienst)

OPTIONS IN DROPDOWNWORSHIP SERVICECENTRAL WORSHIP SERVICE

Islamitisch

✅

✅

Rooms-Katholiek

✅

✅

Israëlitisch

✅

❌

Anglicaans

✅

❌

Orthodox

✅

✅

Protestants

✅

❌

Has consequences in module 'bestuurseenheden'

  • Filter 'bestuurseenheden': combination in filters

  • New + Edit administrative unit (maybe, not for now)

  • New + Edit Related organsation (maybe, not for now)

1/4/2022, Yassin: Can we make it dependent on whether it is present in the data? Instead of hard-coding it that it is not possible? For example, if I create a central Protestant worship service, then we will have to reverse this change.

04/04/2022, Sofie: Good idea, discussed this with Claire and she will develop this as suggested.

04/04/2022, Claire: I will indeed, if we decide to go with the contextual dropdown in new/edit pages.

2. Change events (Veranderingsgebeurtenissen)

NOT in scope as this isn't shown in any filter

CHANGE EVENTWORSHIP SERVICECENTRAL WORSHIP SERVICE

Erkenning aangevraagd

✅

❌

Erkenning toegekend

✅

✅

Erkenning niet toegekend

✅

❌

Erkenning opgeheven

✅

✅

Naamswijziging

✅

❌

Opschorting Erkenning

✅

❌

Onder sanctieregime

✅

❌

Samenvoeging

✅

✅

Wijziging Gebiedsomschrijving

✅

✅

3. Province and municipality (Provincie en gemeente)

  • Only show the one 'provincie' when an specific 'gemeente' is selected.

  • Only show the 'gemeentes' that are located within that province, if a 'provincie' is selected.

4. Position: mandataries/board members (Positie: mandatarissen/bestuursleden)

OPTIONS IN DROPDOWNWORSHIP SERVICECENTRAL WORSHIP SERVICE

Mandatarissen

Mandatarissen

Mandatarissen

Voorzitter van het bestuur van de eredienst

✅

❌

Secretaris van het bestuur van de eredienst

✅

❌

Penningmeester van het bestuur van de eredienst

✅

❌

Voorzitter van het centraal bestuur van de eredienst

❌

✅

Secretaris van het centraal bestuur van de eredienst

❌

✅

Bestuursleden

Bestuursleden

Bestuursleden

Bestuurslid van het bestuur van de eredienst

✅

❌

Bestuurslid (van rechtswege) van het bestuur van de eredienst

✅

❌

Bestuurslid van het centraal bestuur van de eredienst

❌

✅

Expert van het centraal bestuur van de eredienst

❌

✅

Vertegenwoordiger aangesteld door het representatief orgaan van het centraal bestuur van de eredienst

❌

✅

Bedienaren

Bedienaren

Bedienaren

All ministers positions, see 5. 'Positie bedienaar'

✅

❌

There is no 'Penningmeester' in the Central worship services

5. Position minister (Positie bedienaar)

General rule: only worship services have ministers ('bedienaren')

Do we split the positions according to the type of religion?

OPTIONS IN DROPDOWNTYPE OF RELIGION

Eerste Imam in rang

Islamitisch

Tweede Imam in rang

Islamitisch

Derde Imam in rang

Islamitisch

Kapelaan

Rooms-Katholiek

Kerkbedienaar

Rooms-Katholiek

Onderpastoor

Rooms-Katholiek + Orthodox

Parochieassistent

Rooms-Katholiek

Pastoor

Rooms-Katholiek

Officiërend bedienaar

Israëlitisch

Rabbijn

Israëlitisch

Kapelaan van de andere kerken

Anglicaans

Kapelaan van de kerken te Antwerpen en te Elsene (Geünifieerde anglikaanse kerk)

Anglicaans

Bedienaar

Orthodox

Pastoor-deken

Orthodox

Eerste predikant

Protestants

Hulppredikant

Protestants

Predikant bij het voorzitterschap van de Synode

Protestants

Tweede predikant bij het voorzitterschap van de Synode

Protestants

Secretaris bij het voorzitterschap van de Synode

Protestants

We only have one position 'onderpastoor' that is a position in two religions.

BUG to report: Merge to one function:

  • Tweede predikant bij het voorzitterschap van de Synode

  • Secretaris bij het voorzitterschap van de Synode

1/4/2022, Yassin: I did some further thinking and searching online confirming what we now https://www.senate.be/www/?MIval=/Vragen/SVPrintNLFR&LEG=5&NR=9272&LANG=nl . We should check with ISD if Secretaris bij het voorzitterschap van de Synode a type of bedienaar?

4/4/2022, Sofie: Asked ISD for confirmation via e-mail.

🤩Expectations

To be discussed

IN SCOPE = Stories filtering

  • As an end-user, I can only select possible combinations when I combine filters so I can only do relevant searches.

NOT IN SCOPE = Stories creating new items

  • As an end-user, I can only select possible combinations when I create new items (administrative units, positions, persons, organisations, ...) so I'm sure that the system prevents me from making mistakes.

NOT IN SCOPE = Stories editing new items

  • As an end-user, I can only select possible combinations when I edit existing items (administrative units, positions, persons, organisations, ...) so I'm sure that the system prevents me from making mistakes.

🤔Discussion points

  • When changes in the data model or in legislation we always have to check if we have to change the business rules of dropdown lists.

    • A: indeed

  • The order in which end-users fill in or edit the fields is important.

    • A: Not in scope for now. If we do contextual dropdown lists in new/edit functionality then we need a design flow.

  • Should we apply this to all dropdown lists? Will it cause constant maintenance and extra work in the future?

    • A: Scope for now = all dropdown lists in filters

  • Is it easier to work with contexts? Select in advance what you are looking for, f.e. worship services, municipalities, ... It also might be handy when we want to refine the rights and roles.

    • A: To discuss

  • Create separate Jira tickets for changes in filters, creating new items and editing existing items?

  • Order in the dropdown lists: alphabetical or logical?

    • A: Alphabetical is easier to do, logical might be tricky. We go for alphabetical.

  • 1/4/2022, Yassin: I understand that we are doing this investment for the search functions for the read-only data. For the edit screens however, I am for example aware that only a few bedienaren will be registered by ABB. The bedienaren and besturen will be managed from Loket, so it makes you wonder if it's worth it given the timeline (soft go-live in November)

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

Summarized description of the requirements

Filtering

This analysis is about the contextual dropdown in the context of filtering data (bestuurseenheden & personen).

Requirements on filters for bestuurseenheden :

  • "Soort eredienst" options depend on "Type bestuur"

  • "Gemeente" options depend on "Provincie"

  • "Provincie" will have only one option when "Gemeente" is selected

Requirements on filters for personen :

  • "Positie" options depend on the type of the selected "Organisatie"

New items / edit items

The cases of new and edit pages are put aside for now. We might implement them if they can be re-used in Loket later on (mainly for persons and positions).

Requirements on bestuurseenheden :

  • For change events, "Type veranderingsgebeurtenis" options depend on the type of the organzation

  • "Gemeente" options depend on "Provincie" and reverse

  • "Soort eredienst" options depend on "Type bestuur"

  • "Centraal bestuur" option is only shown when a centraale bestuur exists for this "Soort eredienst". If it's shown, then it's mandatory.

Requirements on positions :

  • "Type" ("mandaat", "bedienaar") options depend on the type of the organzation

  • "Rol" (for "bedienaar") depend on the type of religion of the organzation

  • "Mandaat" (for "mandaat") options depend on the type of the selected "Organisatie"

Analysis

I see two cases :

  1. We can deduce the options from the data directly. It's the case for :

    • Province <-> Gemeente

    • Soort eredienst <-> Centraal bestuur field

  2. We can't deduce the options. We can either write down the rules in the frontend or link the options in the db. Both possibilities will require maintenance if the rules change over time. Setting the rules in the frontend will make the maintenance a bit lighter. It's the case for :

    • Soort eredienst <-> Type bestuur

    • Positie <-> Organisatie

    • Type veranderingsgebeurtenis <-> type of org

    • Type ("mandaat", "bedienaar") <-> type of org

    • Rol <-> type of religion of the org

    • Mandaat <-> type of org

Implementation

Data update

We have currently nothing in the db linking municipalities to provincies, and we need it to have the link Provincie <-> Gemeente.

What needs to happen :

  • Grab the link gemeente <-> provincie from other projects like Loket and create a migration from this to ingest it in OP

  • As to how we can model it, using the following allows us to fit with the model used in the "related organizations" tab, which will make it easier later on when we add municipalities and provinces to OP :

  @hasMany('organization', {
    inverse: 'isSubOrganizationOf',
  })
  subOrganizations;

  @belongsTo('organization', {
    inverse: 'subOrganizations',
  })
  isSubOrganizationOf;

Case 1

If we take the example of Provincie <-> Gemeente, I see something like :

  • Pass down the gemeente to the provincie select

  • When querying for the provincie, only get the provincie that has this gemeente as sub-organization if a gemeente is provided. Otherwise, default behaviour.

Case 2

Similar to case 1, but instead passing down the argument directly to the query, we'll have to make a map of the options available for each possibility and load it from there.

If I take Positie <-> Organisatie as an example :

  • Pass the selected organization when selecting a position

  • Depending on the classification of the organization, look at the mapping between positions and organizations and only fetch the related positions from the DB

PreviousFP: Data import script (TO DO)NextFP: Split worship services from other administrative units

Last updated