Currently on the list view, top level tasks can be manually sorted but subtasks cant.
The “vue.draggable.next” library used under the hood supports this.
Right now each top level task has unique position attribute value per the view.
So do subtasks, but their position is not tied to parent in any way.
We’re going to need to rewrite it so that uniqueness is combination of view-parentTask-subtask position rather than just view-parentTask.
Plus a some related position calculation logic. That’s a tough one TBH.
Matter of fact subtasks are still buggy when it comes to pagination.
I don’t think we need to rebuild the way positioning works, but maybe
change the way they are handled in the list view. The way I see it,
subtasks should stick to their parent when moving, but they should be
able to be moved indipentently in the level they are in.
My thinking was, for example, to imagine two parent tasks A and B and then imagine subtasks C and D. The tricky part is when C and D become subtasks of A and also subtasks of B, meaning the user might expect the reordering to be different when tasks C and D are under task A compared to when C and D are the subtasks of D.
I’m not sure though if preserving the order of subtasks uniquely per parent would be critical for users… I think no.
How should it update the position if a task is subtask of two tasks? Immediately or upon refresh?
“How should it update the position if a task is subtask of two tasks? Immediately or upon refresh?”
I think immediately - that’s the current design - when vue.draggable.next emits drop event the new position is calculated based on neighboring tasks and update is sent to positioning service.
On refresh backend SQL returns already ordered list of tasks.
If the goal is preserving the order of subtasks uniquely per parent - I really see no other way than not only sending view ID + new position to positioning service, but also send parent task ID.
This will help the backend SQL in identifying the order of subtasks under this or that parent when supplying frontend with the ordered task list.
If the goal is having the subtasks ordered under parent tasks, but closing eyes on the fact that subtasks order change will propagate to other hierarchies where same subtasks reside under different parent, then it’s probably less complicated - but again, position needs to be still calculated right on frontend.
But overall what’s the use case of re-ordering subtasks?
It really sounds like in most cases we need to just see the order based on start/end/due date or priority - so maybe just sort subtask visually based on that and leave alone the custom re-ordering hussle?
Ideally, subtasks would not be fetched as standalone tasks in the list view, only as subtasks with their parent. Because the position is stored per view, it won’t affect the position of the tasks in other places.