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