Hybrid task with nml

[youri-k]

• blocked by performance problems of creating/duplicating volume tracings

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• create explorative annotation as baseAnnotation and copy the id
• create new task with the copied id as baseAnnotationId
• get task and see the baseAnnotation

Issues:

• fixes Hybrid tasks with given NML  #4117
• fixes Hybrid tasks with given segmentation #4187

---

• Updated changelog
• [ ] Updated migration guide if applicable
• [ ] Updated documentation if applicable
• [ ] Adapted wk-connect if datastore API changes
• [ ] Needs datastore update after deployment
• Ready for review

[youri-k]

Frontend ToDo:

• show field for baseAnnotation in non-bulk view
• adapt the json format to "baseAnnotation": {"baseId": "id"}

[philippotto]

front-end is done!

[daniel-wer]

Code LGTM 👍

Things I noticed:

• (If I create a hybrid task type, then a task with that task type and open that task, I'm only allowed to do volume actions (it's also displayed as type volume in the info tab). Did I miss a step here to get a proper hybrid task?)
• (In the dashboard/tasks view, only a volumebadge is shown for hybrid tasks, but both skeleton and volume should be shown.)
• I see - Both of the above points are solved if the base annotation is a hybrid tracing instead of a volume tracing - that's probably fair for now.
• If I supply a base annotation that is a hybrid tracing to a task with a volume task type, the resulting task is a hybrid task. So basically the base annotation tracing type overwrites the task type tracing type. That is, because the frontend decides what type of tracing there is (and what type of actions the user can take), based on whether there is a skeleton and/or volume tracing present. I would say that is alright for now, but we should probably fix that at some point, it seems un-intuitive.

[philippotto]

Thank you for the thorough testing @daniel-wer! I didn't notice that the base annotation type takes precedence. However, I'd suggest to fix this already in this PR, since I think it's a likely scenario that hybrid tasks should be created and the base annotation is only a skeleton. The other direction ("create skeleton task and base is hybrid") might be less likely, but I think that should be even easier to fix, @youri-k?

So, I guess these two to dos remain for the back end:

• if a hybrid base annotation is provided for a skeleton or volume task, only the respective skeleton or volume tracing should be written into the task base (thus, preventing that the task turns into a hybrid)
• if a non-hybrid base annotation is provided for a hybrid task, then the back end should create an empty tracing for the missing companion tracing

@youri-k Do you agree with this plan?

[CLAassistant]

All committers have signed the CLA.

[fm3]

While I agree that it is quite dubious to fill the optional tracingid fields in the BaseAnnotation objects, I also see that the nearby alternatives are more tedious. Please add a changelog entry before merging

[philippotto]

@fm3 @youri-k Do you think we can land this? As far as I know, the most recent performance logging showed that this is no longer blocked. Is this correct?

[fm3]

I’d possibly add a warning to the user that this is a slow operation, and should not be done with too many tasks at a time, something like this. What do you think @philippotto ? Apart from that, I guess we can merge and deploy.