chore: Remove getTrackedEntity(UID) [DHIS2-17714] #18316
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
enricocolasante
approved these changes
Aug 19, 2024
| @@ -186,11 +191,14 @@ public TrackedEntity validateTrackedEntity(String trackedEntityUid, User user) | |||
| return null; | |||
| } | |||
|
|
|||
| TrackedEntity trackedEntity = trackedEntityService.getTrackedEntity(trackedEntityUid); | |||
| // TODO(tracker) Are these validations enough? Should we check for ownership too? | |||
There was a problem hiding this comment.
We should probably unify this method with the one present in RelationshipOperationParamsMapper when solving this TODO
|
zubaira
approved these changes
Aug 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Big picture
Tracker has multiple services for each entity like tracked entity, enrollment, event and relationship. One is in dhis-api and one in dhis-service-tracker. Our goal is to provide one API (service) per entity that is part of the tracker domain/team.
Trackers architecture splits read/write into exporter services and an importer. So if you want to get data you use an exporter. If you want to insert, update or delete you have to go through the importer. Only then can we ensure integrity of tracker data.
Another goal is that code that provides tracker functionality and is thus owned by the tracker team lives in ideally one maven module (We can settle on a name later on maybe
dhis-service-trackerordhis-tracker).This is a big task that we are going to implement in many small steps.
This PR
getTrackedEntity(String uid)fromTrackedEntityService.getTrackedEntitymethod from the tracker moduleTrackedEntityServicein the service layer. There are still usages of the manager in the service, they are explained below.OperationParamsValidatorneeds to be revisited. I'm not sure if it is sufficient or if we need to use the tracker service to run the appropriate validations. Same goes for theDeduplicationController.DefaultProgramMessageServiceandDeliveryChannelStrategywe still use the manager because they both live in the service core module, so they have no access to the tracker module. These two services will audit the log directly using theTrackedEntityChangeLogService. Despite its name, this service actually generates audit logs, not change logs. However, this is only a temporary solution, as the service belongs to the tracker module and should be relocated to the appropriate module. Once we move it, neither of these two services will have access to it anymore.DefaultTrackerObjectsDeletionServiceis also using the manager, because the proper validations are already run before we reach that point, it's not necessary to run them again.Please note this is a very long PR, but there are a lot of changes that consist of a method signature refactor only.