Add possibility to postpone conflicts resolution

[canonic-epicure]

Our current issues with some of the conflict popups: For example when you have a task that is being delayed and a user is trying save that delay by increasing the task end date, but somewhere later in the network of the plan there is another task that has a "must start/finish on" or "start/finish no later than" constraints that is now causing a conflict dialog to popup, and it is not possible to continue working before resolving that conflict.

The alternative solution to this would be to allow the conflicts as a 4th option in the dialog "save without resolving conflict", simply flagging the task with “hasUnresolvedConflict = true”. This would ultimately cause the totalSlack to be a negative number, indicating/flagging to the end user that something needs to be done to resolve the conflict for that task (The hard constraint should take priority over the relation as in below image).

This would be beneficial for large networks where multiple disciplines are involved in a plan, and the person that updates the end date of its own task have no idea of how to handle potential conflict(s) later in the network. So the person updating should still be allowed to save the delay of its task without necessarily having to handle the conflict right away. Then a planner (or owner of the successor task) comes into the plan, sees the hasUnresolvedConflict flag and negative slack and will make a decision how they should handle the conflict issue. The infinite loop conflicts are fine as they are as they correctly prevents user from making infinite loops, and it makes sense that you cannot continue working without resolving those right away

[canonic-epicure]

Todo:

• [x] The feature itself + tests
• [x] ignoreOppositeDirectionConstraints option
  • [x] The above broke some tests, need to investigate/fix
• [x] As it was discussed during meeting, replace ignoreOppositeDirectionConstraints with custom logic for constraints processing
• [x] Task editor cancel and rollback a transaction when conflict dialog is shown (due to focus out) - bug
• [x] Info column with postponed conflict icon + tests
• [x] Docs
• [x] Localization for Info column
• [x] Description for "Postpone resolution" option
• [x] Position for "Postpone resolution" option (should be the 2nd last one?)
• [x] Localization for "Postpone resolution" option
• [x] Example
• [x] Test for example
• [x] Changelog
• [x] Infinite loop when editing constraint date via cell editor and pushing task's constraint date is earlier than project's start date

[fdyrseth]

When commenting in the "custom logic" that you have made for us in the TaskModel override functions, then the new conflict warning icon does not appear. I think this is because the custom logic (correctly) treats the "must start on" as "start no earlier than" in the forward path and is therefor not considered a conflict.

Is there any way we could indicate this as a conflict too? Maybe the simplest solution for this is to build another flag for that when resulting startDate (of task B in your example) is different from the Must Start On constraint date?

Missing conflict icon:

Custom code:

[canonic-epicure]

Correct, this is what we were discussing in the meeting.

Is there any way we could indicate this as a conflict too? Maybe the simplest solution for this is to build another flag for that when resulting startDate (of task B in your example) is different from the Must Start On constraint date?

Should be doable, however the implementation will need to be in your application, since this behavior is non-standard.

[fdyrseth]

Ok thank you, then we will try to make that as a flag in our solution.

Another issue that appeared: Both allowPostponedConflicts and autoPostponedConflicts seems to do the same, both does auto postpone the conflicts atm. Shouldn't the allowPostponedConflicts still cause the conflict popup to appear? Is that a bug, or am I missunderstanding that usage?

[canonic-epicure]

Sounds like a bug, allowPostponedConflicts should only add an additional resolution option. Can you provide steps to reproduce?

[fdyrseth]

Start project. Create new task "Task C" with must start on 3-Jan-2024 constraint. Add normal finish to start relation from Task B to Task C.

[canonic-epicure]

Thank you, reproduced, checking it.

[canonic-epicure]

Ah, sorry, I was reproducing in the custom build folder, where the autoPostponedConflicts was enabled. Seems to work fine in the development build. Please make sure you have disabled the autoPostponedConflicts config?

[fdyrseth]

Perfect, I was only commenting it out before, but works fine when disabling. Thank you.

[fdyrseth]

We got our task model overwrite working now (see O365TaskModel in image below) and autoPostponedConflicts=false and allowPostponedConflicts=true.

But still get the issue of not calculating negative slack:

1. We create two tasks with normal finish-start must start on that causes conflict.
2. We postpone.
3. Task model override class correctly causes the constraint to be handled as "start no earlier than" on the forward path,and places the activity correctly.
4. Forward and backward paths seems to be correct according to our indicators (red & yellow lines in image above)

[canonic-epicure]

Hm.. This is strange. If you apply the custom logic for MustStartOn constraint, conflict should not arise. And when I enable that logic in the example I sent, it does not arise and I see negative slack:

Can you please provide steps to reproduce it in the example I sent?

[canonic-epicure]

Also might be related to a build, sending a fresh one on email.

[fdyrseth]

It works fine when running in LiveServer (dev code) so not able to reproduce in your files as it works fine there. Tested with your new build too and same issue, so might be something we do in our task model.

[fdyrseth]

Hi again.

We have set autoPostponeConflicts = true for the example below.

In this example the task "MS 1" has a finish no later than cosntraint:

If you look at the video below, the behaviour is a bit strange when the relation is simply ignored when the conflict occurs and is postponed: https://github.com/user-attachments/assets/b565f163-5804-45d8-84d1-ea967f1c79b3

It would make more sense if the milestone were pushed as far as possible by the predecessors until it hits the "no later than" constraint rather than just ignoring the relations. Meaning it should not ignore the relation but it would respect the constraint over the relation. This works perfectly when using "Must start/finish on" constraint, since that locks the task to that constraint date.

We have discussed this before, but it is a bit more clear what we mean in the attached video, and more clear what could be the potential consequences for the successor activities when the remaining network falls to the project start when a conflict occurs.

[canonic-epicure]

Hi. Yes, that was one of the things I was suggesting paying attention to.

In this case "finish no later than" constraint actually does not constraint a task (it can be read as "finish earlier than") - the constraint intervals is open to the left side. So when a conflict happens and dependencies are ignored, and only a constraint is affecting the task's schedule - it is moved to the earliest possible position (ASAP scheduling).

I'm open for suggestions how this behavior can be fixed/improved.

[fdyrseth]

How about when the conflict occurs, the "finish no later than" would behave as "must finish on" constraint, instead of ignoring the dependencies?

[canonic-epicure]

Might work, I'll give it a try tomorrow.

[fdyrseth]

The new build now works with the logic as suggested above so thats very good!

I found anouther issue now:

Here two tasks with the same predecessors and successors gets different slack. Only difference is Task C has a normal start no earlier than constraint, and causes the backward path, and therefor the slack, to calculate wrong for some reason.

[canonic-epicure]

Right, this is expected, because custom constraints processing logic (which was ignoring the "StartNoEalierThan" constraint during backward pass) is disabled. If you enable it, that will restore the negative slack for task C. However, the special processing for "StartNoLaterThan" constraint will be gone (since "StartNoLaterThan" constraint is ignored during forward pass in the custom constraints logic).

[fdyrseth]

So I commented out "taskModelClass : Task" to disable the custom logic, and still produced the example above. Then it should have correct slack, right?

[canonic-epicure]

Nope, commenting out taskModelClass : Task will enable the newest procesing logic for finish no later than

Having it uncommented ignores such constraints during the forward pass, so the conflict does not occur.

[fdyrseth]

Ok I understand, but not sure I agree.

It seems strang that the backward dates jumps 3 days when hitting the constraint date:

It would make more sense that you treat the "start/finish no earlier than" as "must start/finish on" in the backward path, similar to what you implemented in the last build where "start/finish no later than" is treated as "must start/finish on" in the forward path.

So the forward and backward paths are similar just inverted.

[fdyrseth]

... that would then make the "start no earlier than" treated as "must start on" on the backward path as soon as it "hits" the backward path in the gif above.

[canonic-epicure]

But then there will be no negative slack on the predecessor task - that was the motivation for ignoring the "start/finish no earlier than" in the backward pass.

[fdyrseth]

So maybe instead of ignoring the constraints as we discussed earlier, they need to be converted to "must" constraints.

Because now, all negative slack is 0 for all if you have "start no earlier than" on task B and C:

Task A, B and C should instead have -2d in this example, and that would have happened if you "push" the backward path as far to the left as the constraints allows on task B and C. Then task A would also get the backward path 2 days earlier than the forward path: Red line views the suggested backward path

[canonic-epicure]

I have one idea, will try to implement it tomorrow. Hopefully it will work, but no promises yet.

[fdyrseth]

Great, thank you!

[canonic-epicure]

Sorry, that didn't work. Probably you'll need to choose between the negative slack and that special processing for the "FinishNoLaterThan" constraints. Hopefully there's a solution, lets discuss during the meeting.