StefanKock

I discussed with @MateStrysewske that we maybe would reopen #10132 and #10231 to go into a 1.75.x version. That means that this ticket will then be closed as duplicate.

@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...

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...

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.

~~Investigation~~ Known architecture: The timer for a `@Schedule` method that fails (twice) gets automatically explunged. A workaround pattern is known: You have to annotate the called ejb method with `@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)`...

I have a feeling that #10324 is somehow linked to this.

I categorized the linked tickets to have a better overview.

Well for start: Changing anything on the software shall be documented in ticket, and the commit has to be linked to the ticket. How does this come into this automation...

I'm against merging something where the epic and ticket were not discussed/refined first.

The reported problems were caused within 1.76.0-SNAPSHOT and fixed by #3915 [9ecb4dd](https://github.com/hzi-braunschweig/SORMAS-Project/commit/9ecb4dd6f0ea550a270d142fc911733bffecccdc) yesterday. The performance problem might be valid, there is currently no hint what is causing it.