Categories belongig to a series: Duplicated Labels #645
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.
This PR-Draft relates to #634 and #601 .
I "fixed" the current implementation in a way that the labels view now should not be showing duplicated labels anymore.
However, the implemenation is still majorly flawed as indicated in the comments:
https://github.com/jduehring/annotation-tool/blob/0cb527bdaf654e287a1f4ecbfa927d0f9a546bc3/opencast-backend/annotation-impl/src/main/java/org/opencast/annotation/impl/persistence/ExtendedAnnotationServiceJpaImpl.java#L967C9-L969C145
When updating the labels for a series from the master series category, they currently are beeing deleted and newly created each time the app gets refreshed. But since the app tries to keep track of deleted labels, they essentially get duplicated in the background (which can still be seen in the "edit category" view) .
We could probably try to filter all deleted labels and only show the newly created ones, but that doesnt fix the underlying issue of creating more and more (deleted) labels each refresh. Ideally the labels should only be created once and only update, if new lables have been created in the master series category. Unfortunately that does'nt seem as straight forward as it sounds.
I could not implement a working, satisfying solution yet and will discuss this matter with @JulianKniephoff and/or @mwygas in January to hopefully make quick progress here.