In this way it's possible to get all the projects for wich some part of their lenght is
comprehended between the defined start and end dates, with the previous strategy only the
projects which were completely included in the interval were being listed.
FEA: ItEr77S15FilteringEnhancements
If the list of unscheduled projects is empty, the restriction shouldn't be added
or it'll cause a syntax error due to an empty list "o.id IN ()".
FEA: ItEr77S15FilteringEnhancements
When you import a project from the web service, the task elements are not
created yet, so we need to return these projects in the query otherwise they
will be not visible at all for the users.
FEA: ItEr77S15FilteringEnhancements
The new query receives several params from the filters (dates, labels, criteria,
customer and state) and returns the filtered orders.
For the moment it's only used to get the initial list of orders for the projects
list window.
FEA: ItEr77S15FilteringEnhancements
The issue was introduced in commit 05132fd5a7.
Where it was defined an algorithm:
2.4) FSD is not null and FED is not null:
2.4.1) APED is null: Check if APSD is between FSD and FED
This was wrong, it should be:
2.4) FSD is not null and FED is not null:
2.4.1) APED is null: Check if APSD is lower or equals than FSD or APSD is
lower or equals than FED
FEA: ItEr77S04BugFixing
Now the dates filtering the resource load window are checked against the
resources activation periods. Using the following algorithm:
1) If the resource has not activation periods then it should always appear
2) The filter can have null for start and end dates and the activation periods
can have null for end date. So we should define what to do in each case:
Let's define some acronyms:
* Filter Start Date: FSD
* Filter End Date: FED
* Activation Period Start Date: APSD (cannot be null)
* Activation Period End Date: APED
2.1) FSD is null and FED are null: The resource should appear regardless its
activation periods
2.2) FSD is null:
2.2.1) APED is null: Check if APSD is lower or equals than FED
2.2.2) APED is not null: Check if APSD is lower or equals than FED or APED
is lower or equals than FED
2.3) FED is null:
2.3.1) APED is null: The resource should appear
2.3.2) APED is not null: Check if APSD is later or equals than FSD or APED
is later or equals than FSD
2.4) FSD is not null and FED is not null:
2.4.1) APED is null: Check if APSD is between FSD and FED
2.4.2) APED is not null: Check if activation period overlaps filter period
at any point
FEA: ItEr77S04BugFixing
In order to allow switch tasks codes and avoid the issues changing the code
while creating a child, the unique constraint in DB for field code in
order_element table has been removed.
Instead two new constraints methods have been added:
* OrderElement.checkConstraintUniqueCode()
* Order.checkConstraintUniqueCodeInsideOrder()
FEA: ItEr77S04BugFixing
The comparison with the OrderElemen was wrong and it causes that the data stored
was wrong.
Moreover, it was not needed to open the transaction in the bound service method
as it's already opened in PersonalTimesheetModel.
FEA: ItEr77S14BoundUsersWebServices
Now the IntraDayDates methods are used. Most of the changes are in the
tests, since they were using the previous LocalDate methods.
FEA: ItEr77S04BugFixing
Depending on selected node and if it's or not updated from templates the
different buttons are enabled or disabled accordingly.
FEA: ItEr77S12AdaptPlanningAccordingTimesheets
The methods used to calculate the start and end of the task when
moving the task and when allocating in the form were different. This
caused the length of the task to change when being moved.
Now the method used when moving the task is the one always in use,
because it's more precise.
When doing the allocation that calculates RESOURCES_PER_DAY use
IntraDayDates instead of LocalDate so if the first day of the
allocation is partially allocated, the part free is used.
FEA: ItEr77S04BugFixing
* 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
In that way we are sure that everything is removed properly. We have to manually
detach the removed element from its parent in order to avoid delete the parent
too.
FEA: ItEr77S13AllowDeleteOrderElements
