Sormas-project: Extend event participant jurisdiction calculation [3]

[kwa20]

Bug Description

Event participants are pseudonymized for any users when participants have previously been entered. Newly added participants seem to be excluded from that.

Steps to Reproduce

1. Open the event participant tab in any event as any user on a server running the 1.48.1 update.
2. Check event participant list.
3. Compare with servers running 1.48.0.

Expected Behavior

Screenshots

System Details

• Device:

• SORMAS version: 1.48.1/1.48.0
  
  

• Android version/Browser: Chrome, Firefox

Additional Information

[sergiupacurariu]

Additional discussions regarding how the Jurisdiction check is applicable to Event Participants are needed.
The only Jurisdiction policy implemented was Event Participant was accessible to Reporting User (user who created the Event Participant).
Currently, this policy is disabled due to the limitations it has.

[MateStrysewske]

@bernardsilenou

[markusmann-vg]

Discussed with HZI: All users of a SORMAS instance (Gesundheitsamt) can see all data which belong to an event participant and the whole event participant list. If some of the users within one Gesundheitsamt should not see the person's data, they can handle this with the roles & rights management.

[MartinWahnschaffeSymeda]

@bernardsilenou We need a clear chain of "responsibilty" for the event participant that defines who can fully access it.

Our suggestion is as follows:

1. The event participant person has an optional district field in the home address. All users that have access to this district should be allowed to see all data
2. When no district is defined for the person, we can use the district where the event took place as a fallback.

Would this make sense? Or is there a need to separate the responsible district from the district of the persons address / event location?

[bernardsilenou]

Dear All,
The challenge i can see here is that if the district of the home address of the event participant person is not missing, and the reporting user of the event participant has another district, then we would have a situation where users create an event participant and after it sync with the db, their colleagues (surveillance officers) will not be able to see personal data of the entity they just created. This will also prevent them from making corrections.

For cases and contact, seudonimazation do not currently hold when the reporting user has a different district from that of the responsible district. The reporting user always see the personal data. I think we should use the same logic for event participants. Here are the suggested changes:

We can go with a similar logic we uses when a contact is not in the district of the case.

• Separate the event participant (EP) entity from the person entity. I will attach a mockup.
• Add a reporting users to EP, this user will always see the personal data of the EP.
• Add a responsible region, district and community to EP. We can limit the options of this field to only take the region and district of the address of the EP person, or that of the event.

We can use the district of the event as default and users can later change it to the district of the address of the person. I discussed with Kay we realized using the address of the person as default may not be optimal because the officer at the district of the event should deliberately assign the event participant to another district.

Another issue i can think of is the fact that we block confidential data from users who do not have the user role account in the district of the EP. We also make events public and every user can add an event participant. A simple way to test is a person is in an event it just to create the EP and duplicate detection of EP will validate it, see image attached. We also need a solution for this.

I will discuss with the team and come up with a final solution by tomorrow.

[MartinWahnschaffeSymeda]

@bernardsilenou Thanks for your reply.

Splitting the UI for event participant and the event participant person makes sense, but should not be part of this issue.

Always giving the reporting user access to the event participant makes sense. Actually we already have this information, but aren't displaying it yet.

I'd suggest to not add responsible region/district/community to the event participant at this point, to keep it simple for the user.

Instead we could give the following users full access to the event participant

1. reporting user
2. user in jurisdiction of event location
3. user in jurisdiction of event participant address

Also we should display the reporting user in the UI of the participant, similar as we are doing it for cases and contacts.

[bernardsilenou]

@MartinWahnschaffeSymeda I have a meeting to discuss this with him today and hope to have a toms up. I will comment soon

[bernardsilenou]

@MartinWahnschaffeSymeda We can go with your solution with this minor adaptation. The goal is to give only one jurisdiction the right to edit the ep data at any time and also allow the jurisdiction of the event to be able to share the ep entity to another jurisdiction (not only jurisdiction of the address of the ep person) and by doing that loose writing right to the ep entity.

We give the following users full access to the event participant:

1. reporting user of the ep. When a case is retrospectively linked to an event, the reporting user of the ep is the user doing the linking, may not necessarily be the reporting user of the case. If the ep was already crated by another user and another user then link the case to the event should maintain the initial reporting user of the ep, thus we do not override the reporting user.
2. users in jurisdiction of event location. If this user decide to share the ep with another jurisdiction (this can be the jurisdiction of the address of the ep person, or any other jurisdiction), this user will only have read assess but not write assess to the ep anymore. They still see sensitive data for ep.
3. users in jurisdiction of event participant address. This should not be an automatic assignment and should not be limited to the jurisdiction of the address of the person. If user in jurisdiction of event has not shared the ep with user in the jurisdiction of the address of the ep person, then the user in the address of the ep person should have only read right. This constrain is necessary to make sure that at one point in time, only one jurisdiction has the writing right to the ep entity.

In other words:

• The default user who has the write and read assess to the ep is the reporting user
• If User is in the jurisdiction of event and not the reporting user of ep and ep has not been assigned to another jurisdiction, then they have read and write assess
• If User is in the jurisdiction of event and not the reporting user of ep and ep has been assigned to another jurisdiction, then they have read assess only
• It should be possible to assign ep to jurisdiction other than the address of the person. This is a new variable to be added to ep to permit the sharing and transferring of ownership.
• All users in the new jurisdiction that the ep has been assigned to has read and right assess to ep even if they are not the reporting user nor belonging to the jurisdiction of the event

@MartinWahnschaffeSymeda @MateStrysewske @markusmann-vg do you agree with this? is there something missing?

[MartinWahnschaffeSymeda]

So the todos would be:

• [ ] add fields for responsible region and district to the event participant
• [ ] display reporting user in event participant form
• [ ] reporting user should always have full access
• [ ] when no responsible region/district is defined, users in the jurisdiction of the event have full access
• [ ] when a responsible region/district is defined, users in the jurisdiction of the event have only read access
• [ ] users in the responsible region/district have full access
• [ ] All other users only have pseudynomized read access

@bernardsilenou Please double check that I got you right.

[bernardsilenou]

@MartinWahnschaffeSymeda Thanks for the excellent summary, I have minor comments:

So the todos would be:

• [ ] add fields for responsible region and district to the event participant
• [ ] display reporting user in event participant form
• [ ] reporting user should always have full access

condition that the region/district of reporting user == responsible region/district of ep
if region/district of reporting user != responsible region/district of ep, then reporting user should have only read access. This condition would help that when reporting user in not in the jurisdiction of the event, they would be forced to assign their jurisdiction when adding the ep to the event

• [ ] when no responsible region/district is defined, users in the jurisdiction of the event have full access
• [ ] when a responsible region/district is defined, users in the jurisdiction of the event have only read access

if responsible region/district of ep is defined and != jurisdiction of the event, users in the jurisdiction of the event only read access

• [ ] users in the responsible region/district have full access
• [ ] All other users only have pseudynomized read access

[MartinWahnschaffeSymeda]

if region/district of reporting user != responsible region/district of ep, then reporting user should have only read access. This condition would help that when reporting user in not in the jurisdiction of the event, they would be forced to assign their jurisdiction when adding the ep to the event

@bernardsilenou That would contradict the general pattern that reporting users always have the right to edit. Otherwise the user would not be able to fix a wrong initial input (e.g. accidentally picking the wrong district).
If the goal is to make sure the responsible district is set, I would suggest the following:

• [ ] When an event participant is created by a user with a jurisdiction different to that of the event, the user's region and district should be pre-filled for the event participant. Otherwise the fields are empty initially.

[bernardsilenou]

@MartinWahnschaffeSymeda Thanks for the correction, Your solution is better