The old method working with hours is now deprecated so its use is
discouraged. Eventually it will be phased out. Change calendar test
method to test the new method.
FEA: ItEr60S19TimeUnitDataType
saved and that order already saved in the DB
It's necessary to check if any of the codes in an order that's going
to be saved contain duplicated values comparing also against that very
same order in the DB.
Order codes must be unique. There's a case where it may not be any
duplicated code in an order, neither in other orders, but a unique
constraint violation still may happen.
Imagine the following scenario:
order
|-- order1(1, 'code1')
|-- order2(2, 'code2')
The first time _order_ is persisted, everything goes OK. However if the
value of codes are swapped, that is:
order
|-- order1(1, 'code2')
|-- order2(2, 'code1')
None code is repeated within the order, however as data is persisted one by
one, when _order1_ is going to be saved into DB, the value of
_order2.code_ is still 'code2', resulting into an unique code constraint
violation.
This is a limitation of the backend database and how unique fields work.
The best thing to do is to check there's no other orderelement with the
same code value in the DB (except for the one that's going to be saved).
FEA: ItEr60S04ValidacionEProbasFuncionaisItEr59S04
The code of an Order element must be unique. On creating two new Order
elements, being their code null at that time, the process that checks
whether two or more codes are repeated detects there are duplicated
values. Null values should not be consider when detecting duplicated
codes.
FEA: ItEr60S04ValidacionEProbasFuncionaisItEr59S04
being checked for the own children of an Order instead of all its
children
* Some code refactoring (use Set instead of List, reuse constraint
validation implemented in Order)
FEA: ItEr60S18CambiosPantallaArbolPedido
There was a constraint in Order that checked the code of an order was
unique in the whole system. This validation was done for each Order,
which slowed the process when saving. This validation is now moved to
OrderModel.save. It does the same funcionality but faster since now it's
no needed to retrieve all order elements for each order.
FEA: ItEr60S18CambiosPantallaArbolPedido
* Move code that updates field 'initialStatus' to method updateDisabilitiesOnInterface(), since initialStatus has to be updated always before calling this method
FEA: ItEr60S18CambiosPantallaArbolPedido
The signature of the factory methods is changed, now they receive
EffortDuration instead of a Integer. CalendarException#getHours method
removed.
FEA: ItEr60S19TimeUnitDataType
There was a bug after applying optimizations on how the tree is loaded.
Now it's necessary to reload the tree from directly java code. Before it
was done via reloadBindings()
FEA: ItEr60S18CambiosPantallaArbolPedido
It changes the interface for the selection of orders.
It adds the filtered by labels and criterions to the workingProgressPerTask report.
FEA : ItEr60S15AnA04S11RFAdaptacionFiltradosInformes