StefanKock
StefanKock
### Problem Description Follow up to #3481 and #4153: Develop ideas how to decrease the time spent for persisting data that needs to be created very often (usually case, contact...
### Problem Description Findings on `PersonService.getSimilarPersonDtos` by #8697: 1. The first query in `PersonService.getSimilarPersonDtos` fetches `Person` entities with secondary queries for sub-entities (at least `Location`, `PersonContactDetail`) to then convert to...
### Situation Description & Motivation Data collected for cases, contacts and the other core entities has to be deleted automatically after a given time period. #### Use cases - Travel...
### Problem Description #9903 showed that users without user roles make data sync breaking. `UserDtoHelper.fillInnerFromDto` is to complicated (imho): 1. Fiddles around with userroles if not empty. This helps to...
Fixes #6700. Draft because I slowly replace joda-time - [x] Decide how to deal with null values in `DateHelper.getStartOf`/`getEndOf` -> Keep `null -> now()` behaviour for this ticket, follow-up ticket:...
### Situation Description & Motivation #### Use cases ### High-Level Explanation ### Timeline ### Tasks - [ ] #6052 - [ ] #6054 - [ ] #6053 - [x] #4842...
### Problem Description In #6700 (PR #9942) it was found that many methods of `DateHelper` (`getStartOf`/`getEndOf`/`add`/`substract`) relied on joda-time to convert `null` to `now`. ### Proposed Change 1. Let all...
### Situation Description & Motivation #### Use cases ### High-Level Explanation ### Timeline ### Tasks - [ ] #7401 - [x] #7306 - [x] #7342 - [x] #7456 - [x]...
### Problem Description As shown by the following analysis, many `getAllAfter` methods show an inperformant pattern: 1. The `"Entity"Service.getAllAfter` method takes some seconds. As shown in https://github.com/hzi-braunschweig/SORMAS-Project/issues/8946#issuecomment-1129937176, this can be...