Task position index when dropping

[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)

[tasnim]

Hi,

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

    listeners : {
        taskDrop({ taskRecords, targetColumn })  {
            console.log(targetColumn.tasks.indexOf(taskRecords[0]));
        }

Best regards,
Tasnim

[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

[tasnim]

Hi,

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 !

[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).

aaaaaa.mp4

example

(1.7 MiB) Downloaded 36 times

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

[tasnim]

Hi,

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?

[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 515 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 515 times

[tasnim]

Hi,

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,
Tasnim

[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?

Thanks

[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.

Regards,
Ghous