Tue, 13 Jan 2015 09:58:54 +0100fixed bug 28530: can't enter 2nd matched amount in Match LC Costs
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 13 Jan 2015 09:58:54 +0100] rev 25815
fixed bug 28530: can't enter 2nd matched amount in Match LC Costs

When trying to edit the 2nd line in Match LC Costs, UI didn't allow to enter
then matched amount field. After this failure it was needed to reload the
whole page in order make it work again.

The problem was in this situation validation for amount fields is triggered for
all selected records including the new one where the amount is '', it was tried
to be converted to BigDecimal resulting on a JavaScript exception thrown.

Fix check if the amount has a value (or 0) to only sum it in this case.

Wed, 14 Jan 2015 09:39:32 +0100Fixes bug 28554: No error is shown now in oracle creating LC from Goods receipt
Unai Martirena <unai.martirena@openbravo.com> [Wed, 14 Jan 2015 09:39:32 +0100] rev 25814
Fixes bug 28554: No error is shown now in oracle creating LC from Goods receipt

The problem was in 'SELECT PROCESSED INTO v_Processed FROM M_LandedCost WHERE M_landedcost_ID=v_M_LandedCost_ID' statement. If no result is given in the select, in postgres no value is inserted in v_Processed but it works, but in oracle it fails. To fix this an check has been added to execute this statement only when v_M_LandedCost_ID is not null.
An if statement has been added in case v_M_LandedCost_ID is null and v_m_Inout_ID is not (Goods Receipt window), to prevent adding, updating or inserting Landed Cost Cost records when the Goods Receipt is processed.
Finally, in case of updating, the restriction of not being able to change landed cost header has been removed. This was causing problems when launching Cost Background for a Goods Receipt with Landed Cost Cost records, because this process creates the Landed Cost Header and assigns to Landed Cost Cost records.

Thu, 08 Jan 2015 13:08:27 +0100Related to issue 28534: Fix Copyright
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 13:08:27 +0100] rev 25813
Related to issue 28534: Fix Copyright

Thu, 08 Jan 2015 12:50:05 +0100Related to Bug 28531: Fix backdated is not correctly set with big amount of data
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 12:50:05 +0100] rev 25812
Related to Bug 28531: Fix backdated is not correctly set with big amount of data

createCostingRuleInits method inside CostingRuleProcess.java cleares session every 100 records, and if this happens then the reference to current Costing Rule is missed, so the code that sets the fix backdated from is not properly done (rule.setFixbackdatedfrom(startingDate)). To avoid this the Fix Backdated From is set before creating Costing Rule Inventories.

Thu, 08 Jan 2015 12:30:31 +0100Fixes Bug 28534: Fix Backdated From is now displayed properly.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 12:30:31 +0100] rev 25811
Fixes Bug 28534: Fix Backdated From is now displayed properly.

'Fix Backdated From' now is only displayed when 'Backdated Transactions Fixed' is set to Yes.
Also a callout has been added to clear the value in 'Fix Backdated From' when is hidden.

Wed, 07 Jan 2015 19:31:01 +0100Fixes bug 28531: Fix Backdated fails when backdated from is before starting date.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 07 Jan 2015 19:31:01 +0100] rev 25810
Fixes bug 28531: Fix Backdated fails when backdated from is before starting date.

A check has been added to be sure that fix backdated from date is not earlier than starting date of the costing rule.
Also some code has been changed to handle correctly the error messages and return them properly to the user.
Finally the reference of Fix Backdated From Parameter in Fix Backdated Transactions Process Definitio has been changed from Date to DateTime.

Wed, 31 Dec 2014 16:16:00 +0100Fixes Bug 28487: Fixed Null Pointer Exception.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 16:16:00 +0100] rev 25809
Fixes Bug 28487: Fixed Null Pointer Exception.

The problem was that in updateBDCostingTimeRange function inside AverageCostAdjustment class, the code was trying to get the movement date of a Inventory Transaction related to a Costing record. But not all costing have Inventory Transaction, so it was giving a NPE.
Now, if there is a previous Costing record than the one created due to a backdated transaction, this Costing will be shortened till transaction process date, and the new Backdated costing record will start at that moment.
This only happens the first time that a related transaction is found that is not a backdated transaction, because if is done with a backdated transaction time overlap can happen.

Wed, 31 Dec 2014 13:50:58 +0100Fixes bug 28509: Inventory Amt Update now works with negative stock.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 13:50:58 +0100] rev 25808
Fixes bug 28509: Inventory Amt Update now works with negative stock.

In this case the Qty Count and Qty Book have been reverted in the Physical Inventory Lines and negate them to make them positive, maintaining the difference between them to create the same transaction quantity.

Also getInventoryClosingCost function in AverageAlgorithm has been changed to negate the cost obtained from an inventory closing when the movement qty is positive (closing from negative to 0), because the cost obtained was negative, and this is wrong.

Wed, 31 Dec 2014 11:03:15 +0100Fixes bug 28502: Inv Amt Update takes into account Costing Rule warehouse dim
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 11:03:15 +0100] rev 25807
Fixes bug 28502: Inv Amt Update takes into account Costing Rule warehouse dim

The problem was that the process was checking if the warehouse in Inventory Amount Update is null or not, and if not, it uses it. This is correct when the Costing Rule is set as Warehouse Dimension, but if is not, it should not use it, and even if the Costing Rule is not set as Warehouse Dimension and the warehouse field is hidden in Inventory Amount Lines, it is filled with the Warehouse set in session value.

Wed, 07 Jan 2015 10:18:24 +0100Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 07 Jan 2015 10:18:24 +0100] rev 25806
Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized

The method OrganizationStructureProvider.initialize should be synchronized, because otherwise it could be executed concurrently. The first thing the method does it to check if it the OrganizationStructureProvider has been already initialized, but this is not enough to prevent the concurrent initializations.

One of the consequences of the concurrent initializations is that the three maps used in that method (naturalTreesByOrgID, parentByOrganizationID and childByOrganizationID) can be left in an inconsistent state, resulting in the a 100% CPU usage when trying to access them.

Mon, 12 Jan 2015 13:02:24 +0100related to bug 28545: added jUnit test case
Asier Lostalé <asier.lostale@openbravo.com> [Mon, 12 Jan 2015 13:02:24 +0100] rev 25805
related to bug 28545: added jUnit test case

Fri, 09 Jan 2015 10:46:48 +0100fixed bug 28545: filters in HQL Query tables don't work in some cases
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 10:46:48 +0100] rev 25804
fixed bug 28545: filters in HQL Query tables don't work in some cases

Filters in HQL Query tables didn't work for columns having a different column
name than its alias.

This was caused because the reaplcement was not properly done because it didn't
take into account the table alias.

Table alias was added when fixing issue #28432

Fri, 09 Jan 2015 07:48:24 +0100related to bug 28541: added FICTest.class to AllWebserviceTests suite
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 07:48:24 +0100] rev 25803
related to bug 28541: added FICTest.class to AllWebserviceTests suite

Fri, 09 Jan 2015 07:45:56 +0100related to bug 28541: added test case
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 07:45:56 +0100] rev 25802
related to bug 28541: added test case

Fri, 09 Jan 2015 07:44:53 +0100fixed bug 28541: date value in DateTime reference changes to current date
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 07:44:53 +0100] rev 25801
fixed bug 28541: date value in DateTime reference changes to current date

When a DateTime reference column is hidden in grid, the date part was set to
current date when navigating to form view.

This was caused by an incorrect conversion to UTC where current date was set.

Wed, 07 Jan 2015 16:02:36 +0100Fixes issue 28537: Grid is loaded properly after scrolling it and sorting it
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 07 Jan 2015 16:02:36 +0100] rev 25800
Fixes issue 28537: Grid is loaded properly after scrolling it and sorting it

In this changeset [1] a change was done to prevent modifying improperly the totalRows property of the grid after scrolling. This code was meant to be executed after scrolling the grid, and to check it the lastScrollTop property and the getScrollTop() function of the grid body were compared. This check works properly when event that triggered the datasource request was the grid being filtered or a new page being fetched due to scrolling the grid.

The problem was that the check did not work properly when the datasource request was triggered due to having sorted the grid. In this case, the totalRows property should be left as is. To fix this, a new flag is used to control when the datasource request has been triggered by a sorting event.

[1] https://code.openbravo.com/erp/devel/pi/rev/c51dce7e9fd3

Fri, 16 Jan 2015 10:29:45 +0000Merge temporary head for 3.0PR14Q3.5
RM packaging bot <staff.rm@openbravo.com> [Fri, 16 Jan 2015 10:29:45 +0000] rev 25799
Merge temporary head for 3.0PR14Q3.5

Mon, 12 Jan 2015 16:30:00 +0000Added signature for changeset 84cf6c6fe9b1
RM packaging bot <staff.rm@openbravo.com> [Mon, 12 Jan 2015 16:30:00 +0000] rev 25798
Added signature for changeset 84cf6c6fe9b1

Mon, 12 Jan 2015 16:30:00 +0000Added tag 3.0PR14Q3.5 for changeset 6861ab13dc52
RM packaging bot <staff.rm@openbravo.com> [Mon, 12 Jan 2015 16:30:00 +0000] rev 25797
Added tag 3.0PR14Q3.5 for changeset 6861ab13dc52

Mon, 12 Jan 2015 16:29:59 +0000Update AD_MODULE version to 3.0PR14Q3.5 3.0PR14Q3.5
RM packaging bot <staff.rm@openbravo.com> [Mon, 12 Jan 2015 16:29:59 +0000] rev 25796
Update AD_MODULE version to 3.0PR14Q3.5

Fri, 09 Jan 2015 15:18:45 +0100fixed bug 28552: big numbers are changed in some cases
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 15:18:45 +0100] rev 25795
fixed bug 28552: big numbers are changed in some cases

Big numbers are modified in case their scientific notation represntation ends
with zeros, trailing zeros were removed. So, ie., 3.5E10 was changed to 3.5E1
this is: 3.5.

The problem was caused by fix for #26132 which tries to transform scientific to
decimal notation (and then remove trailing zeros, which is correct). But it
expected 3.5E+10 instead of 3.5E10, so in latter case, which is actually used
it didn't do the transformation.

The fix accepts scientific notation with both + and no +.

Wed, 24 Dec 2014 11:11:43 +0100Fixes issue 28379: Value from field is not lost after setting it with a process
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 24 Dec 2014 11:11:43 +0100] rev 25794
Fixes issue 28379: Value from field is not lost after setting it with a process

This issue was caused from a bug in the OBViewGrid.processFICReturn function. There was some code that meant to save in the grid the value of fields that were not being shown in the grid, and that therefore were not returned by the datasource when the grid was loaded. The faulty condition to check if the value of the field was present in the grid was the following:

if (field && !this.getRecord(rowNum)[field.property]) {

This condition is not proper because it does not check if the field is visible in the grid or not. This condition will evaluate to true if the value of that field is null, even if the field is being shown in the grid. Due to this when the value of the Storage Bin field was erased, its new null value was stored in the list of edited values of the grid, and this value took precedence over the Storage Bin value picked in the process.

To fix this, the condition has been improved to check if the field is actually being shown in the grid.

Wed, 07 Jan 2015 10:18:24 +0100Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 07 Jan 2015 10:18:24 +0100] rev 25793
Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized

The method OrganizationStructureProvider.initialize should be synchronized, because otherwise it could be executed concurrently. The first thing the method does it to check if it the OrganizationStructureProvider has been already initialized, but this is not enough to prevent the concurrent initializations.

One of the consequences of the concurrent initializations is that the three maps used in that method (naturalTreesByOrgID, parentByOrganizationID and childByOrganizationID) can be left in an inconsistent state, resulting in the a 100% CPU usage when trying to access them.

Thu, 25 Sep 2014 17:06:26 +0530Fixes Issue 27679: can't use FK drop down if grid is already filtered by a relative date
Shankar Balachandran <shankar.balachandran@openbravo.com> [Thu, 25 Sep 2014 17:06:26 +0530] rev 25792
Fixes Issue 27679: can't use FK drop down if grid is already filtered by a relative date

Convert relative dates in criteria to absolute dates.

Tue, 30 Dec 2014 12:57:04 +0100Fixes issue 28501: Window is property loaded having read only tabs
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 30 Dec 2014 12:57:04 +0100] rev 25791
Fixes issue 28501: Window is property loaded having read only tabs

There was a problem in the way read only tabs were initialized. It was caused by this changeset [1], which fixed a problem related with read only tabs loaded lazily. The problem is that under some circumstances the setReadOnly function of the standard view was called without it being fully initialized. The setReadOnly invokation ended up calling the OBViewGrid.resetEmptyMessage function, and tried to execute this line:

this.view.parentView.isShowingTree

The problem is that the parentView property of the view was not set yet, so an error was thrown. To fix this, now the code to update some view properties based in its uiPattern value is executed after the parentView property is properly set.

[1] https://code.openbravo.com/erp/devel/pi/rev/052c07be4a9ddd2b2a61bd60e948370c53482cb4

Wed, 24 Dec 2014 13:29:10 +0100Fixed bug 28482: Exchange rate and Converted Amt in Add Payment
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Wed, 24 Dec 2014 13:29:10 +0100] rev 25790
Fixed bug 28482: Exchange rate and Converted Amt in Add Payment

The Exchange rate and Converted amount fields were not properly updated when 2 financial accounts (the first one of them with different currency than the invoice and the second one with the same currency) are selected sequentially into the Add Payment process.

Casue: the conversion rate was wrongly sent back to the JS as a String ("1") instead of using a number. The OB.APRM.AddPayment.paymentMethodMulticurrency function checks the received conversion rate is a number before updating the converted amount. Since the converted amount wasn't a number but a string, the amounts were not updated.
After the fix, the conversion rate is sent back using a integer 1

Mon, 22 Dec 2014 12:06:48 +0100Related with issue 28454: Add comments to function
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 22 Dec 2014 12:06:48 +0100] rev 25789
Related with issue 28454: Add comments to function

Fri, 19 Dec 2014 09:45:01 +0100fixed bug 28454: can't nullify fields when 1st edition is in grid
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 19 Dec 2014 09:45:01 +0100] rev 25788
fixed bug 28454: can't nullify fields when 1st edition is in grid

When the first edition in a tab was done in grid view, it was not possible to
nullify any field.

The problem was null values are only sent to backend for fields present in the
standard view. To get those fields form.getFields() method was invoked, in order
to improve performance, form fields are only loaded when the form is opened 1st
time, so if the form view was not opened before this check, all nulls were
removed from the request. As this was cached, all further editions were using this
incorrect cache.

The fix consists in not using form.getFields() methods but to get the fields from
view.formFields which is guaranteed to be loaded one the window is opened.

Tue, 09 Dec 2014 18:59:11 +0100Fixed bug 28362 c_invoice_post creates unnecesary contentions
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 09 Dec 2014 18:59:11 +0100] rev 25787
Fixed bug 28362 c_invoice_post creates unnecesary contentions

Avoiding the join with m_pricelist and c_doctype contentions are solved

Tue, 09 Dec 2014 18:55:38 +0100Fixed bug 28360 c_order_post creates unnecesary contentions
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 09 Dec 2014 18:55:38 +0100] rev 25786
Fixed bug 28360 c_order_post creates unnecesary contentions

Avoiding the join with m_pricelist the m_pricelist contention is solved

For update sentence is deleted in c_orderline selects because the
c_orderline is bloqued with the main select and is redundant and
causes unnecessary contentions.