Opened 3 years ago

Closed 3 years ago

# diagrams drawn differently (broken?) between r13705 and r13868

Reported by: Owned by: jc Chris Nelson high TracJsGanttPlugin critical 1.0

(background to this ticket: #11761)

Task #502 has a start date (1.4.2014) and blocks #503 (no dates) and #504 (no dates). This is drawn correctly by r13705

Tried just redrawing the DummyMilestone: result - basic chart now drawn differently. #502 shown AFTER #503, #504, and #504 now has a red line to #278.

See the attachment pdf below:

### comment:1 Changed 3 years ago by jc

Summary: diagrams drawn differently (broken) between r13705 and r13868 → diagrams drawn differently (broken?) between r13705 and r13868

### comment:2 Changed 3 years ago by jc

Background data, some relevant tables from the db: see below

Last edited 3 years ago by jc (previous) (diff)

### comment:3 Changed 3 years ago by jc

Looking at 502,503,504: with r13868, 503 and 504 are anchored to 26.march.2014 which is the due date for the DummyMilestone.

503, and 504 have no explicit dates set.

In r13705 they were drawn after 502 - as 502 blocks 503 which blocks 504 - cascade effect.

Last edited 3 years ago by jc (previous) (diff)

### comment:4 Changed 3 years ago by jc

Removing due date from the milestone cause 503 and 504 to be anchored to 'today'

### comment:5 Changed 3 years ago by Chris Nelson

Description: modified (diff)

### comment:6 Changed 3 years ago by Chris Nelson

Description: modified (diff)

### comment:7 Changed 3 years ago by Chris Nelson

Description: modified (diff)

### comment:8 follow-up:  14 Changed 3 years ago by Chris Nelson

Trying to understand the scenario (there are quite a few more tickets in the screen shots than in the ticket Description).

• DummyMilestone has a due date of 2014-03-26
• That milestone includes tickets 502, 503, 504, 279, 283, 280, 277, 278, 429
• Some tickets have dependencies and subtasks. I think this works out to:
 ID Blockby Blocking Parent Start 277 279 283 279 277 280 277 283 283 429 278 502 503 2014-04-01 503 502 504 504 503

This used to be drawn correctly: 502 starts on April 1st and 503 and 504 follow. Now 503 and 504 show the wrong start dates (not after 502's finish).

### comment:9 follow-up:  15 Changed 3 years ago by Chris Nelson

Please confirm the table of ticket attributes in the previous comment and provide your chart invocation ([[TracJSGanttChart(milestone=DummyMilestone, ...)]]).

(Do you know of TicketImportPlugin? If you confirm the table above, I'll put it into a CSV and import it into my system to test with.)

### comment:10 Changed 3 years ago by jc

Here's the data from ticket_change:

 ticket time field newvalue 277 2014-03-11 blockedby 277 2014-03-11 blocking 278 277 2014-03-15 parents 283 278 2014-03-11 blockedby 278 2014-03-15 parents 502 2014-05-24 blockedby 502 2014-05-24 blocking 503 503 2014-05-24 blockedby 502 503 2014-05-24 blocking 504 504 2014-05-24 blockedby 503

subtickets subtickets

 parent child 283 277 278 429

mastertickets

 source dest 277 278 279 277 280 277 502 503 503 504

ticket_custom

 ticket name value 277 billable 1 277 blockedby 279, 280 277 blocking 278 277 complete 60 277 due_assign 2014-03-10 277 due_close 2014-03-15 277 estimatedhours 0.0 277 hours 0 277 internal 0 277 parents 283 277 totalhours 0.0 277 userfinish 277 userstart 2014-05-23 278 billable 0 278 blockedby 277 278 blocking 278 complete 0 278 due_assign 278 due_close 278 estimatedhours 54.0 278 hours 278 internal 0 278 parents 278 totalhours 278 userfinish 278 userstart 429 billable 1 429 blockedby 429 blocking 429 complete 429 estimatedhours 0.0 429 hours 0 429 internal 0 429 parents 278 429 totalhours 0 429 userfinish 429 userstart 502 billable 1 502 blockedby 502 blocking 503 502 complete 30 502 estimatedhours 7.0 502 hours 0 502 internal 0 502 parents 502 totalhours 1.0 502 userfinish 502 userstart 2014-04-08 503 billable 1 503 blockedby 502 503 blocking 504 503 complete 503 estimatedhours 4.0 503 hours 0 503 internal 0 503 parents 503 totalhours 4.0 503 userfinish 503 userstart 504 billable 1 504 blockedby 503 504 blocking 504 complete 504 estimatedhours 0.0 504 hours 0 504 internal 0 504 parents 504 totalhours 0 504 userfinish 504 userstart

### comment:11 follow-up:  19 Changed 3 years ago by jc

Invocation is [[TracJSGanttChart(milestone=dummymilestone)]]

### comment:12 Changed 3 years ago by jc

To summarise:

• This is dummy data, for testing only
• tickets in the 200s to 400s should be "unrelated" to 500s (apart from being in same milestone)
• 278 and 283 are tickets I used to group subtasks (black bar with underlying tasks) -> subtickets
• I can't quite remember the significance of the mastertickets at the moment ...
• The only tickets with explicit Start Date / Due Date are:
• 277-userstart-2014-05-23 and
• 502-userstart-2014-04-08 from the ticket_custom table
• it's worth noting that ticket_change contains many values for userstart and userfinish for each ticket - these are the values shown in the milestone diagram on the LHS for each ticket - and were correct in r13705.
Last edited 3 years ago by jc (previous) (diff)

### comment:13 follow-up:  18 Changed 3 years ago by jc

It's probably simpler just to pursue the 500s tickets. I moved them to a new milestone

(BTW the database is full of MANY other real tickets - which could also be affecting the scheduling(?))

With just the 3 tickets, 502,503,504 I get the diagram shown in the pdf below. 502 is in April (here the 8th) as expected, 503 and 504 are placed at the end of July. This is the due date of the milestone.

If I change the Start Date of 502 to 1.4.2014, the position of 502 changes as expected. 503 and 504 remain at 31.7.2014.

If I then change the milestone Due Date to 31.5.2013 then 503 and 504 are moved to 31.5.2014. (again see pdf below for all of this)

### comment:14 in reply to:  8 Changed 3 years ago by jc

• DummyMilestone has a due date of 2014-03-26

DummyMilestone originally had a due date of 31.7,

• I moved it to 26.3 to see what'd happen
• In the end I set the milestone to have no due date.

### comment:15 in reply to:  9 Changed 3 years ago by jc

Please confirm the table of ticket attributes in the previous comment and provide your chart invocation ([[TracJSGanttChart(milestone=DummyMilestone, ...)]]).

(Do you know of TicketImportPlugin? If you confirm the table above, I'll put it into a CSV and import it into my system to test with.)

I provided the data you requested, but in https://trac-hacks.org/ticket/11774#comment:13 I suggested we just test 502,503,504 - more simple.

### comment:16 Changed 3 years ago by Chris Nelson

I'm kind of buried with "real work" right now. I'll try to get back to this later in the week.

### comment:17 Changed 3 years ago by anonymous

Thanks for your reply - I'll do some other stuff in the meantime

### comment:18 in reply to:  13 Changed 3 years ago by Chris Nelson

It's probably simpler just to pursue the 500s tickets. I moved them to a new milestone

OK.

(BTW the database is full of MANY other real tickets - which could also be affecting the scheduling(?))

Yes and no. :-/

• Yes: when the background ticket rescheduler is invoked, it 1) finds all active goals (open milestones, active tickets of the type configured to be "milestone" tickets), 2) finds all the tickets required to meet those goals, 3) schedules all those tickets. If you use a schedule=none Gantt, you should see what's in the db, not scheduling done in/for the Gantt.
• No: when you tell the Gantt schedule=asap or schedule=alap, it ignores the dates -- if any -- in the database and just schedules the tickets that meet the selection criteria (e.g., goal=self).

With just the 3 tickets, 502,503,504 I get the diagram shown in the pdf below. 502 is in April (here the 8th) as expected, 503 and 504 are placed at the end of July. This is the due date of the milestone.

If I change the Start Date of 502 to 1.4.2014, the position of 502 changes as expected. 503 and 504 remain at 31.7.2014.

If I then change the milestone Due Date to 31.5.2013 then 503 and 504 are moved to 31.5.2014. (again see pdf below for all of this)

OK. I'll try to look at that now.

### comment:19 in reply to:  11 Changed 3 years ago by Chris Nelson

Invocation is [[TracJSGanttChart(milestone=dummymilestone)]]

The Gantt chart defaults to ALAP scheduling. This may affect what you see in your charts as some dates change.

### comment:20 Changed 3 years ago by Chris Nelson

OK. Looking at the 500s-only attachment.

1. In the first chart, 502 has an explicit start date and the milestone has a due date. An ALAP schedule is built from the due date backwards so the milestone is placed, 504 is before that, 503 before that, then 502 is considered. Since 502 has an explicit start date, it's placed there on the chart, creating slack between 502 and 503.
2. Changing 502s explicit start date moves it but there is still plenty of slack; the other tasks scheduled ALAP starting at the milestone and working back. I don't find this unexpected.
3. Changing the due date of the milestone shifts the milestone and the tasks without explicit dates but does not affect 502 (which has an explicit start date). Again, I don't find this unexpected.

If you created these charts with schedule=asap, I believe you would find that the the milestone would remain fixed on its due date but all three tasks would move when 502's start date was changed.

You might also be surprised to find that if you change the milestone due date to be before 502's start date that you'll have left-pointing FS dependency arrows. The chart isn't smart enough to resolve conflicts in two explicit dates and relies on your eyes to see the wrong-way arrow and fix something. (It might be useful to color tasks with explicit dates a different color so you could quickly see what could be changed to fix the conflict but I don't see that happening soon.)

### comment:21 Changed 3 years ago by Chris Nelson

I find it hard to see what's happening in tracjsganttMoveFrom.r13705.to.r13868.pdf; the charts are at a different scale/format (week vs. day) and the initial conditions are well stated. If you still have an issue after my explanations, above, let me know. There *is* significant refactoring of the scheduling algorithms in recent commits. It used to do:

• some complex stuff for ALAP
• some complex stuff for ASAP (which was based on, but diverged from ALAP)

now I have

• one complex, direction-agnostic scheduler
• invoke it with a few different arguments for ASAP and ALAP

I would expect -- and have seen in my test data -- that this eliminated exceptions and errors that arose from the algorithms diverging before. Which is not to say it's bug free, some of the helper functions for the directions may be wrong.

### comment:22 Changed 3 years ago by jc

Quick feedback - thanks very much for looking at this Chris.

It seems I set the schedule option to alap in trac.ini on 26th May (while trying to debug problems originating in https://trac-hacks.org/ticket/11761 ). Up to then it was always asap.

My trac server is rebooting at the moment. I'll get back with results of redrawing with asap for all the diagrams in about 1/2 hr. It'd be great (and rather embarrasing for me!) if this is all that was wrong.

Last edited 3 years ago by jc (previous) (diff)

### comment:23 Changed 3 years ago by jc

Resolution: → invalid new → closed

Yes, after a long reboot - it seems the diagrams are "back to normal" which is a big relief - I haven't exhaustively tested this. I'll reopen if there's are problem.

Now I'm back to finding out why schedule and schedule_change tables are not written to - which was the "original" problem. (#11761 -> #11773)