* TaskElements are marked or not as updatedFromTimesheets
* TaskElement start date is set with a START_IN_FIXED_DATE constraint to the
first date in the timesheets
* TaskElement end date is set to the last date in the timesheets if this is
later than the current end date of the task
* Depending on if the task is marked as finishedFromTimesheets, a progress of
type TIMESHEETS is added or not. If the task is finished, the end date is set
according to last date in the timesheets
* TaskElement size and position is updated in the Gantt
FEA: ItEr77S12AdaptPlanningAccordingTimesheets
It has been added a new method ICommand.isPlannerCommand() to define if a button
should be added in the planner toolbar or in the common toolbar (save and cancel
buttons).
For the moment, we are using a hard-coded value to know how many buttons we
should add in the plannerToolbar. At this moment we have 2 buttons: reassign and
adapt planning.
FEA: ItEr77S12AdaptPlanningAccordingTimesheets
When a task is moved in the Gantt, the constraint changes and it could causes
that some of its siblings should be moved, because of the parent element is
moved too.
FEA: ItEr77S04BugFixing
The background position of the current day and deadline was outside the
visible area in the timetracker watermark columns when it was on the
last day of the interval.
A better alignment with the tasks layer (reducing the 3px max deviation)
on this cases can be achieved by revamping how lines and borders are
represented on the watermark layer.
FEA: ItEr76S04BugFixing
The background position of the current day and deadline was outside the
visible area in the timetracker watermark columns when it was on the
last day of the interval.
A better alignment with the tasks layer (reducing the 3px max deviation)
on this cases can be achieved by revamping how lines and borders are
represented on the watermark layer.
FEA: ItEr76S04BugFixing
doAfterCompose instead of constructor.
When doAfterCompose is run, we are sure we are ready to send messages to the
client side.
FEA: ItEr76S04BugFixing
doAfterCompose instead of constructor.
When doAfterCompose is run, we are sure we are ready to send messages to the
client side.
FEA: ItEr76S04BugFixing
When a task is potentially modified is not needed to change the start
and the end date. This was causing two invokations of the
"dependencies" algorithm. Now only one is done.
Although the constraint is not applied it must be provided. Otherwise
the dominating forces would not take it into account. Normally this
wasn't a problem since if the secondary point date changes it was
provided. But it can happen that the secondary point doesn't change,
in that case the constraint must still be taken into account.
When a task is potentially modified is not needed to change the start
and the end date. This was causing two invokations of the
"dependencies" algorithm. Now only one is done.
Although the constraint is not applied it must be provided. Otherwise
the dominating forces would not take it into account. Normally this
wasn't a problem since if the secondary point date changes it was
provided. But it can happen that the secondary point doesn't change,
in that case the constraint must still be taken into account.
The order in the deletion of the different objects related with the task was
wrong and it was causing an exception.
Moreover, the exception was breaking the flow of execution in our application
and preventing that the size of container was updated.
FEA: ItEr76S04BugFixing
The order in the deletion of the different objects related with the task was
wrong and it was causing an exception.
Moreover, the exception was breaking the flow of execution in our application
and preventing that the size of container was updated.
FEA: ItEr76S04BugFixing
