diagrams drawn differently (broken?) between r13705 and r13868

[jc]

(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

Installed latest version of tracjsgantt r13868 (using easy_install).

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:

[jc]

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

[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.

[jc]

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

[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).

[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.)

[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

[jc]

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

[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.

[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)

[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.

[jc]

Replying to ChrisNelson:

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.

[Chris Nelson]

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

[anonymous]

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

[Chris Nelson]

Replying to jamescook:

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.

[Chris Nelson]

Replying to jamescook:

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.

[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.)

[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.

[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.

[jc]

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)

Thanks for all your help