🆔FP: Roles and Rights

FP in GS21 - Development in GS22

Status Feature Passport

STATUS	OWNER	DATE
In proposal	Sofie	14/04/2022 + 01/05/2022
Peer review	Yassin
In refinement - Design Research
In refinement - Technical Research/Feedback	Claire	05/05/2022 + 06/05/2022
In development
In QA/ Testing
In Final state

EPIC = OP-942: User roles and rights

Analysis

This part of the feature passport is owned by the analyst

Current state

Currently (01/05/2022) we have access rights for a single graph (not one graph per administrative unit).

1. Administrative units

Only two types of administrative units are in OP:

• Worship services

• Central worship services

2. Roles

We have three roles in OP:

2.1. lezer

• 457 persons have context Lezer

  • Every ABB employee automatically has the role of reader.

• They can only read and not edit.

2.2. editeerder

• 16 persons have context Editeerder, Lezer

  • 2 OP (Yassin and Espérance)

  • 10 LOW

  • 3 locatiesecretariaat (temporary, for manual data manipulation)

  • 1 ISD (Katleen L.) (temporary, for manual data manipulation) (can be changed to 'lezer'?)

• A limited number of colleagues are given the role of editor.

• They can add new information and change existing information via the 'bewerk' button.

• At the moment only colleagues from ISD, LOW and Locatiesecretariaat have that role

2.3. beheerder

• 1 person has context beheerder

  • 1 OP (Sofie)

• At the moment the rights are similar to the rights of the role of 'editeerder'.

Problems

As of GS20 we want to onboard other administrative units. This means that more editors will be added to keep the data up-to-date.

As it is organised now, an editor can edit all administrative units. At the moment this is not a problem because we only have worship services in the OP.

1. Administrative units

15 administrative units will be added in total:

4 of them will be added ASAP:

• Gemeente (will be added as the first) - LF list 'master'

• OCMW (will be added as the second) - LF list 'master'

• District (will be added as the third) - LF list 'master'

• Provincie (will be added as the fourth) - LF list 'master'

The other 11 administrative units will be added later (order to be discussed, now in alfabetical order):

• Autonoom gemeentebedrijf - LSVP list 'master', also in LF list

• Autonoom provinciebedrijf - LSVP list 'master', also in LF list

• Dienstverlenende vereniging - LSVP list 'master', also in LF list

• Hulpverleningszone - LF list 'master'?

• OCMW vereniging - LSVP list 'master', also in LF list

• Opdrachthoudende vereniging - LSVP list 'master', also in LF list

• Polders - LOW list 'master'

• Politiezone - LF list 'master'?

• Projectvereniging - LSVP list 'master', also in LF list

• Watering - LOW list 'master'

• Welzijnsvereniging - LSVP list 'master', also in LF list

We wish to keep the number of editors limited:

• to minimize mistakes (we regularly get requests from editors to correct mistakes they made)

• to keep the data quality high

• to keep it simple and maintainable

The caseworkers (dossierbehandelaars) in LOW work per province, that's why we need a minimum of 5 persons who can edit worship services.

We should better evaluate requests for editor roles, or assign editor roles temporary. We now have temporary 4 extra editors for the manual data manipulation.

Question: Can we minimize the number of editors (10) who are now on the list of LOW?

YB answer: Yes, we can request LOW to explain why which colleagues need it.

2. Roles

We might want to add an extra role in the future. If we notice that we need to keep some data 'protected' from editing to keep the data quality high, we need to be more strict. We need to evaluate this when more editors are active.

• Hoofdediteerder (final name TBD)

  • Max 1 or 2 persons

  • They only can change very important fields once they have been entered (KBO number, Name of an administrative unit, ...). These fields will be not-editable for the role 'editeerder'.

Whether or not to add this extra role depends on whether the editors can keep the data quality high on their own and do not need too much adjustment. We still need to evaluate this.

YB Question: Maybe check with Organisatieregister to know how fine-grained their rights structure is, and whether their users experience it?

🤩 Expectations

Editors can only change the data they are responsible for. They have to treat data of other administrative units in a role as 'lezer' and not edit any data even when this data is wrong. They should alert the person(s) responsible for that particular data so the person who is responsible can change this.

This is the only way to give specific persons (or departments) ownership of their data. They are used to this as the SharePoint lists work in the same way.

We need a simple and easy to maintain system, where we can assign editor roles to specific administrative units or a set of administrative units (eg. AGB and APB).

In the workshops with the business, we will decide how many different administrative unit sets we will have. I think we will have a minimum of 2 and a maximum of 8 sets of administrative unit sets.

This is how the potential rights-matrix may look like

Extra columns (sets) might be necessary, but we will encourage the business to minimize this.

Type rol	(Central) Worship services	Municipalities (Gemeente / Provincie / District etc.)	Inter-municipal organizations (AGB, APB etc.)	"Another type of" category (Waterways etc.)
Reader - Lezer	ABB	ABB	ABB	ABB
Editor - Editeerder	Content expert group A	Content expert group B	Content expert group C	Content expert group D
Admin - Beheerder	Sofie + lead content expert	Sofie + lead content expert	Sofie + lead content expert	Sofie + lead content expert

Is there a need for an extra role like superadmin? Yassin and Sofie

🕵️‍♂️ Use Cases

1. have the existing roles per administrative unit (or separate worship services from the other administrative units), examples:

• edit role for worship services: ABB Erediensten case managers ('dossierbehandelaars') can only edit/add worship services or persons related to worship services. They can always add an existing person to a worship service.

  • YB: A person can be involved in several contexts, so I am not sure that we need to relate any rules to edit a person

  • SM: This might indeed complicate things. If we keep it simple than it is possible that an end-user with context 'municipality' can change the contact details of a person originally created in the context of worship services. If end-users use the copy mechanism the right way this shouldn't be a problem. Let's discuss this in-group.

• edit role for IGS which contains 3 administrative units: Those editors can edit/add items in all of those three administrative units and persons related to these organisations.

• restricted view on sensitive data of persons related to worship services: only to view by ISD and LOW caseworkers

  • YB: Maybe I don't understand what you are conveying here: Do we really need a restricted view? We already have the sensitive data flow, where end users are made aware that there is an audit trail + that they have to give up a reason to consult sensitive information.

  • SM: OK, this is indeed probably overkilling.

2. have an extra role for special edits for specific administrative units, examples:

To be discussed if we really need this

• edit the official name of a person or organisation (see refinement ticket 1055: Analyse Names of Organisations (wettelijke naam, alternatieve naam en voorkeursnaam)

  • YB: we need to differentiate between organization and persons and also between names and official names

    • Special rights are needed to edit a first, last or calling name of a person - 100% agree

    • Special rights are needed to edit an official name of an organization (cfr. wettelijke naam) - this is best read-only and should come from KBO only

    • Special rights are needed to edit a voorkeursnaam of an organization (cfr. preflabel) - can be created by an editor, but cannot be edited by an editor afterwards. This requires a context group lead or admin to change it. This will impact LOW work process in case of Naamswijzigingen Change events

    • Special rights are needed to edit an alternatieve naam of an organization - can be created by an editor, but cannot be edited by an editor afterwards. This requires a context group lead or admin to change it.

• only this role can change identifiers like KBO number or RRN.

  • YB: for KBO we have foreseen ample checks, do we really need to take this out of the hands of the editors?

  • YB: for RRN I am not sure about this one, do we also have a check on uniqueness on it? The end-users need to go through the sensitive data flow to edit it.

3. Should rights be mutually exclusive? Are we able to handle combining several rights in one end user?

A concrete example

There are two types of rights combinations possible, I will define them as follows:

• Vertical combination: case Yassin he is known in ACM-IDM as editor and reader

• Horizontal combination: future case: Yassin gets added as an Editor for context group A (worship services) and context group B (municipalities) -> check illustrative table in the previous section

• Combining both horizontal and vertical combinations: being admin for context group A + editor for context group B

🤔 Discussion points

1. What is easier to develop/to maintain to separate worship services and the other administrative units or administrative units sets?

• ❌ SOFT SPLIT: on the administrative units results page: end users need to use the filters to find an organization they are looking for. The data is shown in place (all organizations together), end users thus only need to look in one place.

• ✅ MEDIUM SPLIT: work with contexts: end-user needs to select on the home page https://organisaties.abb.lblod.info/ what info he/she wants to consult. The data is never mixed in the overview pages.

• ❌ HARD SPLIT: split the database: completely different portal (only for worship services)

2. Can ACM/IDM be used: depending on the access that is granted you can view and or edit specific information (cfr. contexts in Loket)

A 'gemeente' has a local manager who gives access to the persons who can input data in Loket. OP can act as a local manager.

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

Discussion points for next BRM

• "Are we able to handle combining several rights in one end user?" -> yes, we just need a clear definition of what is expected as a behaviour.

• "Can ACM/IDM be used ?" -> Aad ? 😀 I think so, but I don't know how we can ask them to return x roles for y user.

• Soft/medium/hard split?

  • We said in the preparation meeting that we wouldn't go the hard split, at least not before experimenting with the others, because it'll give us a better view on how and why we would want a split.

  • Medium split is feasable but will come with an exploding indexing time (it's already big, but if we do that, it means we'll have one index per roles combinations). We would have to split all the data in graphs per unit, or per group A/B/C/etc.

  • Soft split is the one we're the closest to currently. It means we can keep everything in one graph. We would need to extend mu-search so that all the users can share an index but also have other roles stating if they can or can't edit some data. It currently does a hash of the user's roles and create an idex for each combination. If we could blacklist/whitelist some roles from this hash, then we could reduce drastically the number of indexes needed (as here they would all share the same indexed data)

Outcome of the BRM

• Soft split with one shared graph (unless the DPO says otherwise but shouldn't)

• mu-search: additive indexes should be our solution. If it doens't work, then it's probably a bug that we want to fix directly in mu-search.

POC Results

• Hard split is feasible, assuming we add a new role (worship-xxx)

• we duplicate persons that have position in adminisstrative units && worship service (two separate graphs)

• users can have one role (unit / worship), or both. In the case they have both, we need to do a soft split (frontend)

• for the soft split, we add "Worship Services / Administrative Units && Worship personen / Administrative Units personen cards in the homepage. We just filter them with api filters (same as what we have now for the tables, except we trigger them in javascript)