Dependency lag not considered when updating calendarModel

[til.schniese]

Thanks for adding the ticket. Can you please give me an ETA for this as well? It would be really important for us to get this fixed, too. Thanks.

[alex.l]

No ETA at the moment. The ticket will get a milestone with target release version after our product management prio it.

[til.schniese]

Just FYI: The Automatic dependency setting not working issue does not seem to be related to Vue and/or resetting the complete inline data only. Instead of resetting the complete array, I tried to just modify the eventModel directly, like the following:

   model.set({
      startDate: e.startDate,
      endDate: e.endDate
    })

But this will result in the same issue.

[til.schniese]

I am afraid I need to push this issue once more (https://github.com/bryntum/support/issues/5788)

I was able to reproduce this in your basic online example as well, it is certainly not related to Vue, it also happens when setting start/end Date on the eventModel directly (I don't event need to replace the whole data field of the store).

Below again the code you can plug into the basic example:

import { SchedulerPro } from '../../build/schedulerpro.module.js';
import shared from '../_shared/shared.module.js';

// region Data

const resources = [{ id: 'r1', name: 'Mike' }];
const events = [
  {
    id: 1,
    resourceId: 'r1',
    startDate: new Date(2017, 0, 1, 10),
    endDate: new Date(2017, 0, 1, 12),
    name: 'A',
    iconCls: 'b-fa b-fa-mouse-pointer',
    calendar: 'start',
  },
  {
    id: 2,
    resourceId: 'r1',
    startDate: new Date(2017, 0, 1, 13),
    endDate: new Date(2017, 0, 1, 15),
    name: 'B',
    iconCls: 'b-fa b-fa-arrows-alt',
    calendar: 'start',
  },
];

const dependencies = [
  {
    id: 't',
    from: 1,
    to: 2,
    lag: 60,
    lagUnit: 'm',
  },
];


// endregion

const scheduler = new SchedulerPro({
  appendTo: 'container',
  resources,
  events,
  dependencies,
  features: {
    dependencies: true,
    dependencyEdit: true,
  },
  tbar : [
   { 
      text    : 'Reset',
      icon    : 'b-fa b-fa-plus',
      color   : 'b-green b-raised',
      onClick : () => {
const e1 = scheduler.eventStore.getById(1);
const e2 = scheduler.eventStore.getById(2);
e1.startDate = new Date(2017, 0, 1, 10)
e2.startDate = new Date(2017, 0, 1, 13)
}
    },
 ],
  startDate: new Date(2017, 0, 1, 6),
  endDate: new Date(2017, 0, 1, 20),
  viewPreset: 'hourAndDay',
  rowHeight: 50,
  barMargin: 5,
  multiEventSelect: true,
  columns: [{ text: 'Name', field: 'name', width: 130 }],
});

Steps to reproduce:

1. Move A to start earlier -> B will follow
2. Click the reset button in the toolbar I added
3. Move A to start earlier again -> B does not follow

This bug will affect everyone that programmatically modifies events e.g. by using set* functions. Thus, I kindly ask you to increase the priority for this because it really messes up our schedule. I think it is worth to look at this asap.

[nickolay]

Hi, as Johan mentioned in the ticket, you should just not be assigning a start date to the e2 if you want e2 to be auto-scheduled according to the dependencies flow.

Assigning a start date creates a constraint "start no ealier than" on the event (since there's clearly an intention to keep the event on some specific date). And this constraint interferes with the dependencies flow.

[til.schniese]

Okay, thanks for the answer. I think the problem is that in our case there is no "intention to keep the event on some specific date" when updating the events. In our case, we fetch the events from an external source. Then, the events might get updated externally (e.g. this could just be a different client using the same scheduler). Now, our scheduler should be updated, thus, all we want to do is to set the events accordingly (because we assume the events we receive are correctly scheduled). So, we just want to refresh the events to this new state (like it is done for the initial load kind of), this should not break the auto-scheduling logic.

Is there any way to achieve this without setting syncDataOnLoad = false. Can we maybe have a flag to enable/disable this automatic constraint setting?

[nickolay]

syncDataOnLoad is not related here - it's the behavior of the startDate field. We'll need to discuss this issue internally.

Right now, what you can try, is to clear the constraint on the event after assigning a start date to it:

e2.startDate = new Date(...)
e2.constraintType = null
e2.constraintDate = null

[til.schniese]

I see, yes, that seems to fix it in the example I provided, thanks. I would encourage you to think about this because the beauty of the inline events array in Vue is, that you don't need to care about the eventModel. That means I was never actually modifying the eventModel.startDate directly, but just updated the events array, so I also don't have much control over the constraint dates, that are set after the update. That's why the syncDataOnLoad = false helped to remove the constraints I guess.

[nickolay]

I see what you mean. We'll consider adding a flag on the project, that will prevent creation of the constraint in this case, but need to discuss this with the colleagues.

Right now, as a workaround, may be in the place where you update the events array, iterate over all events and clear the constraints. If you have scheduler instance that would be:

scheduler.project.eventStore.forEach(event => { ... })

[til.schniese]

Thanks a lot, I think this will do the job for now.