Premium support for our pure JavaScript UI components


Post by chrisb »

Hey guys,

By default - our gantt filters out inactive tasks using taskStore.filter(...)
When a task is filtered out, you can see it missing in the wbs structure (this is good).
Image

However when a task is added below the task immediately preceding the inactive (in this example, we added a successor to 2.1.1.1) the new task's parentIndex overwrites the inactive task, and then all tasks except the one filtered out are shuffled up. You'll notice in the below no update for task 2.1.1.2, and the parentIndex for 2.1.1.3 (the new task) doesn't match it's wbs.
Image

When we send our tasks down from the server, we use the parentIndex and parentId properties on the tasks to build the tree, and this causes a conflict as now two tasks have the same parentId and parentIndex - which means the inactive one doesn't come down the wire.

Not sure exactly where the problem lies here. Are we filtering incorrectly? Is this an issue with inactive tasks? Or with the update logic using the filtered store?

Any advice would be appreciated.

Thanks

Chris


Post by mats »

Makes sense, we have opened this ticket for you to track: https://github.com/bryntum/support/issues/3419


Post by chrisb »

Heya Mats,

Between this issue (which I just noticed is a feature request), and this other issue I reported (https://github.com/bryntum/support/issues/3572), I don't seem to have any way to reliably store the structure of the tasks without running into issues with tasks overwriting. Our tool has been live for a few weeks now and with these issues outstanding, I'm nervous we're corrupting our data.

What is the recommended way to persist the structure of the tasks?

Thanks,

Chris


Post by Maxim Gorkovsky »

Hello.
We never had such use case in mind, so we don't really have any ready-to-go recommendations or guides. But I have some suggestions.

  1. You can use https://bryntum.com/docs/gantt/api/Core/data/Store#function-query method to look through all records, including filtered ones:
    // this method will use unfiltered dataset and print out names of all tasks in the task store
    gantt.taskStore.query(() => true, true).map(t => t.name)
    Using query you can get access to the unfiltered list of children and update index field as you like
  2. You can use a chained store: https://bryntum.com/docs/gantt/api/Core/data/Store#function-makeChained
    Idea is that you create a chained store for a task store and then recalculate WBS index (or parent index, or any other index field) in that store. Chained store shares record instances with the master store, but uses different filters - essentially it is a view of the data.

Post by dongryphon »

You are correct that the parentIndex value is a filtered value and will typically not match the wbs field when a filter is applied.

It sounds like you could use the wbs instead of these index values but maybe I am misunderstanding your comments. You can configure wbs to be a persistent field that will save to the server, so perhaps the serve could use it instead? You will likely also need wbsMode: 'auto' to ensure wbs fields are maintained as you add and remove, but it sounds like you already have that option enabled.

If you need the unfiltered equivalent of parentIndex, it can be computed from the wbs value like so:

Number(wbs.slice(wbs.lastIndexOf('.') + 1))

Or as Max suggested, there are perhaps ways to compute the data needed.

I will await your thoughts before embarking on https://github.com/bryntum/support/issues/3419


Post Reply