[REACT] Need user guide for gantt scheduling cycle dependencies

[rodel.ocfemia]

Hi,
We would like to request for gantt user guide about how scheduling cycle dependencies are being calculated. Right now we have several dependencies suspected of being flagged as scheduling cycle. The dependency lines are displayed as red lines.

Another issue we have right now is if Start Date is later than Finish Date, bryntum automatically recalculates the Finish Date to make it the same as Start Date. So we just need some documentation that we can share to the users.

If you have the whole user guide, it would be better. It does not need to have example codes. We just need something we can show to users.

Thanks

[marcio]

Hey rodel.ocfemia,

We have a detailed guide regarding task scheduling here https://bryntum.com/products/gantt/docs/guide/engine/gantt_events_scheduling

This guide will clarify how the calculation works.

[rodel.ocfemia]

Hi Márcio,

Thanks for the user guide. But I am looking for the specific documentation how scheduling cycle are calculated, but I could not found it in the task scheduling document.

We currently have several dependencies that have red lines and are suspected of being a scheduling cycle and we need to confirm how bryntum calculates those.

Thanks

[arcady]

Hello,

I don't think that our definition of a cycle is something unusual... A task & dependecies structure like A -> B -> C -> A ..where task A pushes task B which pushes Task C which pushes task A...

If you are searching for a way to detect if a dependency is invalid then ProjectModel has validateDependency method:
https://bryntum.com/products/gantt/docs/engine/classes/_lib_engine_quark_model_gantt_ganttprojectmixin_.ganttprojectmixin.html#validatedependency

Best regards,
Arcady

[rodel.ocfemia]

Hi,
Can you pls confirm why some dependency lines are red? Per my testing it turns red if the dependency is scheduling cycle. If it is true, our users are asking explanations why some of the dependencies are turning red as per image below.

MicrosoftTeams-image.png (5.91 KiB) Viewed 265 times

[alex.l]

Hi,

We do not have any logic to mark dependencies as red, except Critical Paths feature https://bryntum.com/products/gantt/docs/api/Gantt/feature/CriticalPaths
which is not relevant to any cycles and conflict resolution. In fact, we do not allow to continue in case of cycled dependency or any other conflicts, until user fixed it, because any further calculations are not possible.
Your case looks very strange on a first sight, we need a test case to reproduce this behaviour.

Thanks!

[rodel.ocfemia]

Hi,
We have feature to enable and disable Critical path. I tried enabling or disabling critical path, but the red dependency lines still exist.

I tried to load our actual data to bryntum example gantt code, but unable to reproduce the issue. Any other clue why some dependency lines are turning red?

In our app, these red dependency lines are displayed once we do "Enforce Dependency" or setting manuallyScheduled=false.

Critical Path disabled:

Dependency-red-lines1.PNG (16.8 KiB) Viewed 238 times

Critical Path enabled:

Dependency-red-lines2.PNG (18.6 KiB) Viewed 238 times

[alex.l]

In our app, these red dependency lines are displayed once we do "Enforce Dependency"

We do not have this feature, I do not follow what to do to reproduce that. Might that be your code that mark dependency that color?

We need a runnable test case to help you. Unfortunately, I am out of ideas what's happened and how to reproduce this.

[rodel.ocfemia]

I also don't remember implementing custom dependency line colors. These red dependency lines are displayed only when we set manuallyScheduling = false.

[rodel.ocfemia]

I found this code, probably done by other developers. Is this something that can override the color of the dependency line? I'm unable to verify this in my localhost because the issue is happening only in customer site and I don't have their data in my local.

.b-sch-foreground-canvas > svg .b-sch-dependency.b-inactive {
    stroke: red !important;
    stroke-dasharray: none !important;
}