-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Remove getTrackedEntity(UID) [DHIS2-17714] #18316
Conversation
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably unify this method with the one present in RelationshipOperationParamsMapper when solving this TODO
Quality Gate failedFailed conditions See analysis details on SonarCloud Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
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-tracker
ordhis-tracker
).This is a big task that we are going to implement in many small steps.
This PR
getTrackedEntity(String uid)
fromTrackedEntityService
.getTrackedEntity
method from the tracker moduleTrackedEntityService
in the service layer. There are still usages of the manager in the service, they are explained below.OperationParamsValidator
needs 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
.DefaultProgramMessageService
andDeliveryChannelStrategy
we 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.DefaultTrackerObjectsDeletionService
is 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.