Our state of the art Gantt chart


Post by sasha573 »

Hi guys!
I'm obtaining tasks and calendars for the tasks via api and setting it on the gantt via setTasks[] and setCalendars[]. Evetything works fine during the first load.
However, if I'm loading additional tasks via api and resetting both tasks and calendar, I'm receiving the following error.

Capture2.PNG
Capture2.PNG (26.75 KiB) Viewed 1315 times

Does it mean that the calendars should be like a static config that could not be changed once the gantt is loaded?


Post by alex.l »

Hi sasha573
We have https://bryntum.com/products/gantt/docs/api/Gantt/model/ProjectModel#property-calendars property to set/get calendars.
Could you please post the code you used? We need to see the syntax, timing and be able to reproduce this to debugging.
Best of all attach a runnable test case, it allows us to help you faster.

All the best,
Alex


Post by sasha573 »

Thanks Alex, I'll try to prepare runnable test case to share with you.
Just some more details on the issue. The error appears if only I'm ressetting the calendar with previously set calendar child.
Like, for the first load the calendar data is following:

[
  {
    "id": "0",
    "children": [
      {
        "id": "1",
	"name": "Calendar for machine:1",
        "intervals": [
          {
            "startDate": "2022-11-28 03:00:00",
            "endDate": "2022-11-28 05:00:00",
            "isWorking": false
          },
        ],
      }
    ]
  }
]

For the second updated upload, the calendar data includes child with the same id: "1":

[
  {
    "id": "0",
    "children": [
	{
        "id": "1",
	"name": "Calendar for machine:1",
        "intervals": [
          {
            "startDate": "2022-11-28 03:00:00",
            "endDate": "2022-11-28 05:00:00",
            "isWorking": false
          },
        ],
      },
      {
        "id": "2",
	"name": "Calendar for machine:2",
        "intervals": [
          {
            "startDate": "2022-11-29 03:00:00",
            "endDate": "2022-11-29 05:00:00",
            "isWorking": false
          },
        ],
      }
    ]
  }
]

It should be mentioned that the error doesn't appear if the calendar children ids are different during
various gantt updates.
Maybe there is the way to clear data in the gantt's calendar store before uploading updated data?


Post by marcio »

Hey sasha573,

We're looking forward to the project sample to debug your case and assist you.

Regarding the clear calendar data, you can try to use https://bryntum.com/products/gantt/docs/api/Gantt/model/ProjectModel#property-calendars and assign an empty array before assigning that new information, but I believe it won't solve your issue, we would need the code to inspect and find a proper solution to your case.

Best regards,
Márcio


Post by sasha573 »

Hi guys!
I've made changes to inline-data sample in order to replicate the needed behavior (in attachment).
The calendar is assigned to each task child. Clicking on "Change Data" button simulates the api call to receive updated tasks and calendars.
The idea is that user could load task 1, then refresh data and load both task 1 and 2 with respective calendars. The non-working calendar intervals could change upon refresh.
Hovewer, from the attached sample, if we reset existing calendar intervals, only the initially loaded non-working intervals are displayed on gantt. Morover, at some point I'm catchin the following error:

inline-data.7z
(1.73 MiB) Downloaded 70 times
Attachments
Capture3.PNG
Capture3.PNG (16.75 KiB) Viewed 1237 times

Post by alex.l »

Hi sasha573,

Thank you for the clear test case. I checked that and confirmed a bug. Here is a ticket to track the status https://github.com/bryntum/support/issues/5718

All the best,
Alex


Post by sasha573 »

Hi Alex!
Thanks! Could you please prioritize this issue somehow, as the display of non-working calendar events is very crucial for us.


Post by alex.l »

Ok, I've informed our product management about your request.

All the best,
Alex


Post by sasha573 »

Thanks Alex! Looking forward to their reply.


Post by alex.l »

It's assigned to 5.3.x milestone, so it will be fixed with one of nearest releases!

All the best,
Alex


Post Reply