Take into account IntraDays to print bars in Gantt

[kwoot]

(Original Bugzilla Bug ID: 1242)

Date: 2011-11-08 17:22:15 From: Manuel Rego Casasnovas \<rego@igalia.com> To: Jacobo Aragunde Perez \<jaragunde@igalia.com> Version: libreplan-1.2 (1.2.x) Duplicate: 1317) Last updated: 2012-01-03 15:52:01

---

(Note: this issue was migrated automatically with bugzilla2github.py tool )

[kwoot]

Bugzilla Comment ID: 3319 Date: 2011-11-08 17:22:15 From: Manuel Rego Casasnovas \<rego@igalia.com>

In order to calculate the size of progress bar we're not taking into account the IntraDays and just using LocalDate. This is causing different problems that we should fix as a whole.

A concrete issue is explained in the mailing list: https://sourceforge.net/mailarchive/message.php?msg_id=28371250

This should be reviewed and fixed after 1.2 release.

[kwoot]

Bugzilla Comment ID: 3539 Date: 2011-12-21 17:37:25 From: Javier Morán \<jmoran@igalia.com>

[kwoot]

Bugzilla Comment ID: 3540 Date: 2011-12-22 10:21:09 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

Probably the method calculateLimitDateByPercentage in class TaskElementAdapter should be changed. In particular, the way we calculate "advanceDate" (should be an IntraDayDate instead of a LocalDate).

[kwoot]

Bugzilla Comment ID: 3541 Date: 2011-12-22 10:24:29 From: Manuel Rego Casasnovas \<rego@igalia.com>

(In reply to comment #2)

Probably the method calculateLimitDateByPercentage in class TaskElementAdapter should be changed. In particular, the way we calculate "advanceDate" (should be an IntraDayDate instead of a LocalDate).

Yes, you're right. We should change how we calculate that date.

Anyway, take into account that progress are measured with LocalDate no IntraDayDate. Anyway, the variable "advanceDate" in that method should be IntraDayDate as you say.

[kwoot]

Bugzilla Comment ID: 3549 Date: 2011-12-23 13:00:48 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

I've made some changes to use IntraDays to draw the completion bar. The changes are located in TaskElementAdapter -> Adapter -> TaskElementWrapper, method calculateLimitDateByHours.

But these changes don't work correctly in all the circumstances. In particular, they don't work when the resources per day are different from zero. Example:

Create a task with 10 hours, and assign a worker to it with "resources per day" set to 0.5. This will create an assignation of three days, with 4, 4, 2 hours each. The width of the task reaches the middle of the third day (2/4 hours), but the width of the progress bar only reaches a forth part of the third day (2/8 hours).

[kwoot]

Bugzilla Comment ID: 3550 Date: 2011-12-23 13:37:25 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

(In reply to comment #4)

... the width of the progress bar only reaches a forth part of the third day (2/8 hours).

When the progress is 100% (I forgot to mention).

[kwoot]

Bugzilla Comment ID: 3551 Date: 2011-12-23 16:04:39 From: Javier Morán \<jmoran@igalia.com>

In reply to comment 4 and 5.

The end date of the task is right calculated. To calculate the end date of a task in the last day the resources per day which are beign used in the allocation are taken into account.

For instance, with an allocation with this parameters:

• calculate workable days.
• number of hours: 180
• resources per day: 10

The task assigns:

80h 80h 20h

Althouth there are 20h hours assigned the last day the correct drawing of task duration in the end date is:

• number of resources per day: 10
• number of hours last date: 20
• hours to work according with the project calendar that day: 8h

20/10 = 2 hours per resource 2/8 = 1/4 of the size of the day.

So in the case you comment comment 4 and 5:

2/(0.5) = 4 hours per resource => 4/8 = 1/2 of the size of the day.

[kwoot]

Bugzilla Comment ID: 3571 Date: 2012-01-02 12:09:28 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

(In reply to comment #6)

...

2/(0.5) = 4 hours per resource => 4/8 = 1/2 of the size of the day.

This magic is done in UntilFillingHoursAllocation.adjustFinish(). This method knows the value of resources per day, so it's taken into account when calculating the new end date for the task after the allocation.

In the example (a task of 10 hours, 0.5 resources per day, allocations 4-4-2), the task end date calculated by UntilFillingHoursAllocation is an IntraDayDate with an internal EffortDuration of 4 instead of 2. Why? Because it adjusts it to the resources per day. In this case: 2 hours / 0.5 resources per day = 4.

The problem is that I can't access to resources per day from TaskElementAdapter (or I don't know a good way to do it) when calculating the advance end date. So I can't adjust it like UntilFillingHoursAllocation does. In my opinion, doing this would be very complex and doesn't pay the effort (and the overhead). I have worked on two simple patches which fix the most weird cases, I think it would be good enough.

What do you think?

[kwoot]

Bugzilla Comment ID: 3572 Date: 2012-01-02 12:13:43 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

These are the patches I've implemented, I'm pushing them to both master and 1.2 branches since they are an improvement in the situation, albeit not a total solution.

commit 13389197d9b2d9ef8a665ce7e638db71e026224c Author: Jacobo Aragunde Pérez jaragunde@igalia.com Date: Thu Dec 29 15:53:56 2011 +0100

[Bug #1242] Return end date directly when calculating advance and percentage is 100%.

In that case, no calculations are needed, and since the algorithm has some
defects we avoid them.

FEA: ItEr75S04BugFixing

commit 7518270ced8878e0011fb064214b4f2f28739711 Author: Jacobo Aragunde Pérez jaragunde@igalia.com Date: Fri Dec 23 14:14:47 2011 +0100

[Bug #1242] Use IntraDayDate to draw the progress bar in leaf Tasks.

The advance bar was always drawn until the end of the day, even when the task
finished in the middle of the day, causing a weird effect.

FEA: ItEr75S04BugFixing

[kwoot]

Bugzilla Comment ID: 3583 Date: 2012-01-03 15:52:01 From: Jacobo Aragunde Perez \<jaragunde@igalia.com>

Pushed two more patches, one to fix a bug introduced in one of the previous patches and another one to improve the behaviour with competition percentages near, but not equal, to 100%.

commit bf4e13c358926686701450132e7f672587c761fa Author: Jacobo Aragunde Pérez jaragunde@igalia.com Date: Tue Jan 3 14:21:03 2012 +0100

[Bug #1242] Don't allow progress end dates superior to the corresponding task end date.

This situation still happened in tasks with completition near to 100% (for
example 99%) and the 'by hours' calculation method.

FEA: ItEr75S04BugFixing

commit 519389dc4b99808f25842ed4195d1f7bce695018 Author: Jacobo Aragunde Pérez jaragunde@igalia.com Date: Tue Jan 3 13:36:19 2012 +0100

Allow reported hours bar in gantt diagram to be wider than the task.

This bug was introduced when fixing the length of progress bars
(in the commit 13389197d9b2d9ef8a665ce7e638db71e026224c).

FEA: ItEr75S04BugFixing

[kwoot]

commit e7651d8b6cd84af5cd47958a863f336e860b87bd commit bf4e13c358926686701450132e7f672587c761fa commit aa6833443dfc6809cf0149cc740d3b81ba07d519 commit 52111b50e7707f9a985ad2075f60bf3c4634ba9c commit 13389197d9b2d9ef8a665ce7e638db71e026224c commit 7518270ced8878e0011fb064214b4f2f28739711