Our state of the art Gantt chart


Post by Jerther »

Hi!! :mrgreen:

As we're testing our application, the complexity of the the problems grows and they get more and more difficult to replicate since they depend on our equally growing data structure. That's the way it is :geek:

So here I have managed to assemble a working demo and find some steps to replicate a couple of problems. I'm aware that some may just be normal behaviors that look weird to us because of the complexity of the data structure at the scheduler level. So let's see ( a line starting with a :!: indicates a problem):

  • Run the demo.
  • Expand the tasks in row 73
  • Double click on the predecessor of the task of row 73. That'll open the dependency editor.
  • Hit delete.
  • Now drag the task in row 73 just slightly to the left, like 1px, so it gets a constraint date.
  • :!: Notice the dates of the tasks in rows 78 and 79 have changed.
  • Edit the task in row 74 (the milestone), go to the advanced tab and hit the X in the constraint type box. (don't save just yet)
  • :!: The dates of the task in row 78 have changed.
  • Hit cancel in the task editor. Now the weird stuff begins...
  • :!: First, after hitting cancel, you'll notice the tasks have not reverted to their previous state.
  • :!: Notice also that the effort for tasks in rows 78 to 81 have changed. That should never happen.
  • Now edit the milestone in row 74 again and in the advanced tab, remove the constraint type (don't save)
  • :!: Already you can see the milestone has reverted to a normal task, AND has got an effort!
  • Hit save
  • Now drag the task in row 75 to the right a bit.
  • :!: An error in calculateDurationPure occurs. This one we've had many times and seems to be caused by some endDate of some task being BEFORE its startDate. I believe there is multiple ways of getting this condition and this is one of them. One such invalid date got stored in our database and the diagram couldn't be loaded anymore.

I hope this is clear enough so you can extract the technical problems and fix them.

Thanks!


Post by arcady »

FYI we're checking the test case.. it takes a lot of time to debug because of the big size of the dataset. Anyway we'll post results here as soon as all the cases are checked.
Thank you for the report!


Post by Jerther »

This took me a lot of time to control and describe so I can understand it takes a lot of time to debug ;)

Thanks for the follow up


Post by Jerther »

I just noticed the attachment on the original post is gone :( I hope you still have the archive as I'm not sure I do!


Post by arcady »

Jerther wrote: Thu Jun 18, 2020 7:04 pm
  • Edit the task in row 74 (the milestone), go to the advanced tab and hit the X in the constraint type box. (don't save just yet)
  • :!: The dates of the task in row 78 have changed.

This one is expected I'd say. When we reset the milestone constraint it gets shifted to the left (to the task 73 start no earlier than constraint date). And the task 78 is its implicit predecessor so it gets moved in turn.

Since we are on the point of Gantt v4.0.0 release I've checked how it looks in that version. Good news is some of the issues are not reproducible but couple of them are still alive. :)

1st issue is about clearing Constraint type in the task editor: https://github.com/bryntum/support/issues/1331

And 2nd one I'm still debugging. Long story short is task earlyStartDate and earlyEndDate fields got calculated incorrectly at some moment. You can actually spot it easily since indicators feature is enabled and they do not match few tasks start/end dates.
That's the reason why the tasks get moved when it's not expected. I'll update this thread when finish w/ debugging,


Post by Jerther »

Hi Arcady!

It's been a while! Do you have any update since last time you posted?

I'm migrating to 4.1.5 so I hope most weird problems went away ;)


Post by arcady »

To be honest I don't recall how it ended up.. The ticket is resolved but regarding early dates calculation I'm not 100% sure if all those exact issues were done (I just don't have your test case here right now to ensure ..it must be on another machine will check later today).
But anyway upgrading is a good idea since we keep improving the component.
There are still some problems in scheduling that are on our radar and if you see something wrong please let us know!


Post by Jerther »

Hi Arcady!

I found a backup of the test case (attached file). I replaced 2.1.5 by 4.1.5. I believe the data format is still valid although it may use some deprecated stuff.

I reviewed the case and here are the updated steps:

  • Run the demo.
  • Expand the tasks in row 73
  • Double click on the predecessor of the task of row 73. That'll open the dependency editor.
  • Hit delete.
  • Now drag the task in row 73 just slightly to the left, like 1px, so it gets a constraint date.
  • :!: (Still happens) Notice the dates of the tasks in rows 78 and 79 have changed.
  • Edit the task in row 74 (the milestone), go to the advanced tab and hit the X in the constraint type box. (don't save just yet)
  • :!: (Still happens) The dates of the task in row 78 have changed.
  • Hit cancel in the task editor. Now the weird stuff begins...
  • :!: (Still happens) First, after hitting cancel, you'll notice the tasks have not reverted to their previous state.
  • :!: (Still happens) Notice also that the effort for tasks in rows 78 to 81 have changed. That should never happen.
  • Now edit the milestone in row 74 again and in the advanced tab, remove the constraint type (don't save)
  • :!: (Fixed!) Already you can see the milestone has reverted to a normal task, AND has got an effort!
  • Hit save
  • Now drag the task in row 75 to the right a bit.
  • :!: (Fixed!) An error in calculateDurationPure occurs.
Attachments
test-odoo2.zip
(1.26 MiB) Downloaded 95 times

Post by arcady »

Ok, great you have it since I couldn't find it anywhere. I must've dropped it accidentally during my recent hard drive cleanup.
I'll check the rest issues.

P.S. I've edited your test case (just removed the Gantt sources)


Post by Jerther »

Oh, yes, sorry. Makes sens not to include it :)


Post Reply