fix: Use correct get single TE for changelog feature [DHIS2-18541] #20109
Conversation
enricocolasante
force-pushed
the
DHIS2-18541-changelog
branch
from
3deccbd to
c4264fa
Compare
|
|
|
||
| UserDetails currentUser = CurrentUserUtil.getCurrentUserDetails(); | ||
| Set<UID> trackedEntityAttributes = Collections.emptySet(); | ||
| if (programUid != null) { | ||
| Program program = validateProgram(programUid.getValue()); | ||
| validateOwnership(currentUser, trackedEntity, program); | ||
| } else { | ||
| validateTrackedEntity(currentUser, trackedEntity); | ||
| trackedEntityAttributes = validateTrackedEntityAttributes(trackedEntity); |
There was a problem hiding this comment.
is that still needed as ACL on TEA might not otherwise be done?
There was a problem hiding this comment.
Maybe @muilpp can help us understand this better.
This validation is just checking if there are teas, and, if not, it is returning a tracked entity not found.
There was a problem hiding this comment.
this checks if the user has access to the TET, and afaik it's the only place where we do it
There was a problem hiding this comment.
@muilpp I was asking about validateTrackedEntityAttributes.
The other validation is not needed anymore as it is now present in TrackerEntityService
There was a problem hiding this comment.
I'm talking about validateTrackedEntityAttributes too.
We don't validate access to TEAs, if the user has access to the TET, then we grant access to the TETA as well.
If this is already present in TrackerEntityService, then we don't need this line either.
maybe |
Moving
getTrackedEntity()to use the same code as multiple entities has a big impact in a lot of places in the system and it is going to be done in small steps, changing it feature by feature.In this PR we are starting to change tracker ownership service and controller to use the new and correct
getNewTrackedEntitymethod.Changes in this PR
Use
getNewTrackedEntitymethod inDefaultTrackedEntityChangeLogService.Map
trackedEntityTypeid in order to be used in other services that need managed metadata to work properly. Should we formalize that tracker data are always detached and metadata are always managed, even if they are coming from a tracker service?Challenges in tests
TrackedEntityAggregateis loading data in new threads so they have their own transaction and not committed data are not visible in those threads, that is why we cannot use@Transactionalannotation when we are importing data and reading in one one transaction.Common misconfigurations in tests
Next Steps
getTrackedEntity()methods and rename new ones