Person directory: Don't include persons based on entity types the user cannot access

[MartinWahnschaffe]

Problem Description

#10352 pointed out problems accessing persons related to entities the user should not be able to access. For example the person directory currently still lists persons related to a case to a user that does not have the right to view cases.

Proposed Change

Only show persons that are related to entity types the user can access.

Acceptance Criteria

Implementation Details

• [ ] The PersonService.createUserFilter method should not join entity types the user does not have access to (e.g. exclude travelEntryFilter, when the user is not allowed to view travel entries).
• [ ] For consistency we should do the same in PersonService.getAllAfter

Additional Information

[StefanKock]

@MartinWahnschaffe there is some differences between PersonService.getAllAfter and PersonService.createUserFilter.

1. PersonService.createUserFilter already checks if FeatureType.IMMUNIZATION_MANAGEMENT is not FeatureTypeProperty.REDUCED. But this is not considered for
2. PersonService.getAllAfter additionally takes persons in the users district into account.

More methods I found that go into the same direction but implementation is redundant and needs to be changed also:

• PersonService.getAllUuids also does it's own logic to find persons (similar to getAllAfter).
• PersonService.getSimilarPersonDtos looks in every PersonAssociation without considering feature configurations or user rights.
• PersonFacadeEjb.count needs to match PersonFacade.getIndexList (-> createUserFilter).
• PersonService.inJurisdictionOrOwned -> PersonJurisdictionPredicateValidator

The decision which PersonAssociation is allowed will be needed for this ticket and #10352 so we have a dependency between these tickets.

[StefanKock]

After discussing my findings with @MartinWahnschaffe we came to the conclusion that this ticket is to big/wide ranging for a hotfix/micro release. There is a high risk of merge conflicts and diverging changes between development branch.

[StefanKock]

Code review was done, will wait for 1.76.1 to be finished (avoid merge conflicts) and then upstream merge development, recheck tests work and then merge it.

[adinaflorea9]

Verified ticket on the local machine using the latest version of SORMAS from the development branch - 1.77.0-SNAPSHOT(c6512f2).