Clean up merge modal and allow "live-merge" of explorative and project #2935
Conversation
…d explorative merge
…t once to the server
There was a problem hiding this comment.
Nice - two things I noticed:
- I would expect the merge modal to close after a successful merge.
- It's also possible to merge projects/explorative annotations from other datasets. I'm not sure whether this was allowed before (probably?), but I don't think this is wanted behavior and we specifically disallow this when uploading NMLs.
| this.setState({ isUploading: false }); | ||
| Toast.success(messages["tracing.merged"]); | ||
| } else { | ||
| Toast.error("Merging is not supported for volume tracings."); |
There was a problem hiding this comment.
Should this be moved to the messages file as well? Actually, I'm not sure what our current practice regarding the messages.js is anyways? Maybe we should discuss this, not as part of this PR :)
|
Also, does the backend still do some kind of tree renaming when merging a project @fm3? If so, does this happen in this "frontend-merge" case as well (by retrieving the compound project from the server)? I just want to make sure that we don't lose any functionality :) |
|
no, there is no tree renaming, only the node id mapping and the combining of the tracings’ bounding boxes |
|
Sorry for spamming, but I just noticed another thing. When un-checking the checkbox (to create a new tracing when merging), didn't we redirect to that new tracing before? I didn't use the merge functionality for quite a while now, so maybe that wasn't the case, but it feels weird that the user just gets the "Merging successful" message and then nothing happens (apart from the new tracing appearing in the explorative tracings list, which the user cannot see at that point). |
|
Thank you for your feedback, @daniel-wer.
I guess this has never been like that for the case that the user wants to do several merges consecutively. I wouldn't change it now unless some requests it.
Good point, I added a guarding check for that.
Good point! In fact, the code redirects to the new tracing via the router's history.push function, but this doesn't work (I think, since the oxalis controller does not listen to prop changes..). I changed the redirect to use |
|
@daniel-wer @fm3 What do you think about the bounding boxes? When doing the merge via the back-end, the bboxes are combined. When done locally, it's only importing the trees. I'm not sure whether this is an issue at all. The trees will be visible, anyway.. Also, do we want to add a "warning" that the local change can take some time for saving. Or do we want to land this feature together with the chunk saving PR which adds progress indicators. |
|
I'd say it's fine to ignore the bounding boxes when merging in the frontend for now. As you say, the trees are visible anyways. We can create an issue and add it later. |
…ossos into chunk-save-actions
Send save actions in chunks to server
URL of deployed dev instance (used for testing):
Steps to test:
To discuss:
Issues:
Updated migration guide if applicable