Modify

Opened 7 months ago

Closed 7 months ago

#11774 closed defect (invalid)

diagrams drawn differently (broken?) between r13705 and r13868

Reported by: jamescook Owned by: ChrisNelson
Priority: high Component: TracJsGanttPlugin
Severity: critical Keywords:
Cc: Trac Release: 1.0

Description (last modified by ChrisNelson)

(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:

Attachments (3)

tracjsganttMoveFrom.r13705.to.r13868.pdf (379.9 KB) - added by jamescook 7 months ago.
BackgroundDataBetter.pdf (36.2 KB) - added by jamescook 7 months ago.
500sOnlyChangeStartDateChangeMilestoneDueDate.pdf (73.6 KB) - added by jamescook 7 months ago.

Download all attachments as: .zip

Change History (26)

Changed 7 months ago by jamescook

comment:1 Changed 7 months ago by jamescook

  • Summary changed from diagrams drawn differently (broken) between r13705 and r13868 to diagrams drawn differently (broken?) between r13705 and r13868

comment:2 Changed 7 months ago by jamescook

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

Last edited 7 months ago by jamescook (previous) (diff)

Changed 7 months ago by jamescook

comment:3 Changed 7 months ago by jamescook

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 7 months ago by jamescook (previous) (diff)

comment:4 Changed 7 months ago by jamescook

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

comment:5 Changed 7 months ago by ChrisNelson

  • Description modified (diff)

comment:6 Changed 7 months ago by ChrisNelson

  • Description modified (diff)

comment:7 Changed 7 months ago by ChrisNelson

  • Description modified (diff)

comment:8 follow-up: Changed 7 months ago by ChrisNelson

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:
IDBlockbyBlockingParentStart
277279 283
279 277
280 277283
283
429 278
502 503 2014-04-01
503502504
504503

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: Changed 7 months ago by 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.)

comment:10 Changed 7 months ago by jamescook

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: Changed 7 months ago by jamescook

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

comment:12 Changed 7 months ago by jamescook

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 7 months ago by jamescook (previous) (diff)

comment:13 follow-up: Changed 7 months ago by jamescook

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 7 months ago by jamescook

  • 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 7 months ago by jamescook

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.

comment:16 Changed 7 months ago by ChrisNelson

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 7 months ago by anonymous

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

comment:18 in reply to: ↑ 13 Changed 7 months ago by ChrisNelson

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.

comment:19 in reply to: ↑ 11 Changed 7 months ago by ChrisNelson

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.

comment:20 Changed 7 months ago by ChrisNelson

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 7 months ago by ChrisNelson

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 7 months ago by jamescook

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 7 months ago by jamescook (previous) (diff)

comment:23 Changed 7 months ago by jamescook

  • Resolution set to invalid
  • Status changed from new to 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)

Thanks for all your help

Add Comment

Modify Ticket

Action
as closed The owner will remain ChrisNelson.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.