Our flexible Kanban board for managing tasks with drag drop

Post by methodeuser1 »

When dropping a task, is it possible to know the exact destination index of the task inside the target column? (e.g. 0 if it's dropped on the top of the column, 1 if it's dropped after the first task)

Post by tasnim »


You could use this listener to achieve it https://bryntum.com/products/taskboard/docs/api/TaskBoard/feature/TaskDrag#event-taskDrop

    listeners : {
        taskDrop({ taskRecords, targetColumn })  {

Best regards,

Post by methodeuser1 »

Hi tasnim, thanks for the response.

I tried your solution but the code returns always the index of the task after it has been sorted by the taskboard.
I tried to remove all the sorters from the taskboard but the result is always the same...the task is pushed at the end of the column.

Is it possible to obtain the exact index where the task was dropped?

Thanks in advance

Post by tasnim »


Why do you need to get the old index of the task? Maybe after knowing your use case, we can suggest a better way to achieve it 🙂!

Post by methodeuser1 »

In the attachments you can find an example.

Following the example... if a user drags the task E inside the first column, then I want to know the exact index where the task was dropped (in the example it was dragged after the first task so the index should be 1).
My problem is that the taskboard puts this task at the end of the column, not after the first task, and so the code that you suggested returns the index 4.
I don't know how this is possible since i removed all the sorters from the taskboard (even the default one).

(1.7 MiB) Downloaded 32 times

I hope i have explained myself (with my bad english)

Post by tasnim »


From that video, it looks like an unexpected behavior, Are you able to reproduce it with our online demo here https://bryntum.com/products/taskboard/examples/basic/ ? What version are you using?

Could you please provide the steps to reproduce the issue?

Post by methodeuser1 »

Are you able to reproduce it with our online demo here?
No, in the demo the behavior is right.

What version are you using?
@bryntum/taskboard: 5.6.5
@bryntum/taskboard-angular: 5.6.5

Could you please provide the steps to reproduce the issue?
I wish I could but there is a lot of code and I don't know which configuration/handler can be part of the issue. Can you give me a list of handlers that may be the cause of the problem (like onTaskDrop, onBeforeTaskDrop,...)?

In order to remove all sorters I inserted the following code:

aa.png (20.15 KiB) Viewed 457 times

Also I tried to print the onSort event and it seems that there are no other sorters configured

bbb.png (14.58 KiB) Viewed 457 times

Post by tasnim »


It's really difficult to say what can be causing the issue without testing it. Would it be possible to attach a runnable test case here so we can download it and check it locally? If you're not comfortable sharing it here, then you can send us at this email: support@bryntum.com

Best regards,

Post by methodeuser1 »

Ok I think I've found the problem.

In the attachments you can find an example video zipped and you can also replicate this problem using
the demo you suggested (https://bryntum.com/products/taskboard/examples/basic/)

The only sorter in the taskboard is the default one (weight)

When you drag a task between other two tasks, the taskboard updates its weight to be in the middle of the two:

  • 2 tasks in the same column
    • Task A (weight 100)
    • Task B (weight 200)
  • If I put Task C between those two, its weight will become 150
  • If I put Task D between A and C, its weight will become 125
  • ....
    Before dragging the task J, the situation is the following:
  • Task A (weight 100)
  • Task I (weight 101)
  • Task H....

Now If I drag Task J between A and I, for some reasons its weight becomes 103.

When dragging tasks, shouldn't the taskboard also increase the weight of the subsequent tasks?


(2.3 MiB) Downloaded 24 times

Post by ghulam.ghous »

Hi there,

Thanks for providing us with clear steps. I have confirmed the behaviour and it seems a bug. I have created a ticket here https://github.com/bryntum/support/issues/8677 to investigate and fix the issue.


Post Reply