Mon, 16 Mar 2015 18:39:38 +0100Related to issue 29211: Update copyright
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 16 Mar 2015 18:39:38 +0100] rev 26192
Related to issue 29211: Update copyright

Tue, 10 Mar 2015 13:58:57 +0100Fixes issue 29211
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Tue, 10 Mar 2015 13:58:57 +0100] rev 26191
Fixes issue 29211
Cannot complete a goods receipt with a line without attribute set value if it has a related prereservation.
Added coalesce when inserting to get default value

Mon, 16 Mar 2015 18:01:47 +0100Fixes issue 28727: Use proper attribute names in the valueMap of the combo
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 18:01:47 +0100] rev 26190
Fixes issue 28727: Use proper attribute names in the valueMap of the combo

The ListGrid.setValueMap function expected a valueMap that is an array, where each position contains an object with two properties: id and _identifier (OB.Constants.ID and OB.Constants.IDENTIFIER constants). The identifier property was not being properly named, so the valueMap did not contain the proper values.

Mon, 16 Mar 2015 16:57:41 +0100Fixes issue 28727: valueMap is properly initialized in pick and execute windows
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 16:57:41 +0100] rev 26189
Fixes issue 28727: valueMap is properly initialized in pick and execute windows

The problem was that when a line in a pick and execute grid was edited, the valueMap of its OBFKComboItems was not properly initialized. The initialization is done in the OBPickAndExecuteGrid.processColumnValue function.

Before the Openbravo combos was refactored, the columnValue parameter used to contain the full valueMap of the combo in its entries attribute. This atribute was passed to the OBPickAndExecuteGrid.setValueMap, and the valueMap of the combos was initialized. The problem was that since the combos was refactored the columnValue parameter no longer contained the entries attribute, because the FIC now only returns the selected value. To fix this, in this case the valueMap is built manually based on the column value and identifier. This valueMap is passed to the OBPickAndExecuteGrid.setValueMap function to initialize the field valueMap.

Mon, 16 Mar 2015 16:42:25 +0100Related with issue 28727: Checks if the okButton exists to prevent error in log
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 16:42:25 +0100] rev 26188
Related with issue 28727: Checks if the okButton exists to prevent error in log

Mon, 16 Mar 2015 16:35:31 +0100Related to issue 29171: Update copyright
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 16 Mar 2015 16:35:31 +0100] rev 26187
Related to issue 29171: Update copyright

Mon, 16 Mar 2015 00:07:30 +0530Fixes Issue 29171:The sales order is not taking into account the unit price of
Atul Gaware <atul.gaware@openbravo.com> [Mon, 16 Mar 2015 00:07:30 +0530] rev 26186
Fixes Issue 29171:The sales order is not taking into account the unit price of
the product when is 0

Corner case regression, when ever unit price is set to zero in the price list

Mon, 16 Mar 2015 14:56:47 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 16 Mar 2015 14:56:47 +0000] rev 26185
CI: merge back from main

Mon, 16 Mar 2015 14:41:30 +0000CI: update AD_MODULE to version 26182
RM packaging bot <staff.rm@openbravo.com> [Mon, 16 Mar 2015 14:41:30 +0000] rev 26184
CI: update AD_MODULE to version 26182

Mon, 16 Mar 2015 10:34:58 +0100fixed bug 29284: onCreateDefault not executed for appended non mandatory cols
Asier Lostalé <asier.lostale@openbravo.com> [Mon, 16 Mar 2015 10:34:58 +0100] rev 26183
fixed bug 29284: onCreateDefault not executed for appended non mandatory cols

In Oracle new non mandatory columns with a onCreateDefault appended to a table
did not execute the onCreateDefault.

Current fix recreates the whole table in this case. A complete fix where the
onCreateDefault is executed in this case without the need of recreating the table
will be implemented in the scope of the "Prevent Table Recreation" project (see
issue #29270).

Wed, 11 Mar 2015 11:07:30 +0100Fixes issue 29224: Filters work properly in Return from/to P&E window
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 11 Mar 2015 11:07:30 +0100] rev 26182
Fixes issue 29224: Filters work properly in Return from/to P&E window

The problem was that in this changeset [1] the way the distinct queries (done to populate the fk filter dropdowns) was modified. The query is different, and the way to process its results too. The change done in the result processing caused this issue. The query done to populate the Attribute Set Value drop down is the following:

select distinct attributeSetValue,attributeSetValue.description FROM MaterialMgmtShipmentInOutLine as iol left join iol.attributeSetValue as attributeSetValue join iol.shipmentReceipt as io where io.businessPartner.id = 'A6750F0D15334FB890C254369AC750A8' and io.processed = true and io.documentStatus <> 'VO' and io.salesTransaction = true and (select iol.salesOrderLine.orderDiscount from MaterialMgmtShipmentInOutLine as e where e.id = iol) is null and iol.client.id in ('0', '23C59575B9CF467C9620760EB255B389') AND iol.organization in ('E443A31992CB4635AFCAEABE7183CE85','0','19404EAD144C49A0AF37D54377CF452D','B843C30461EA4501935CB1D125C9C25A') AND (io.movementDate >= (now() - 90) or (case when (select ('Y') from OrderLine as ol where ol.salesOrder.id = 'F0D6700E7BD6499FA76C6D94014714E8' and ol.goodsShipmentLine = iol) is null then false else true end) = true) ORDER BY attributeSetValue.description

And this is the result returned in the test I did:

1 42EA0E631BDD4ED69D8C30723A5E81C8 [identifier: L582, entity: AttributeSetInstance], L582
2 NULL, NULL

With the previous way of processing the results the second record was ignored, but with the new one a NPE was being thrown.

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

Wed, 11 Mar 2015 11:07:30 +0100Fixes issue 29224: Return reason filter works properly in Return from/to P&E
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 11 Mar 2015 11:07:30 +0100] rev 26181
Fixes issue 29224: Return reason filter works properly in Return from/to P&E

The problem was that in this changeset [1] the way the distinct queries (done to populate the fk filter dropdowns) was modified. The query is different, and the way to process its results too. The regressi
on was caused because some HQL tables build their distinct queries manually in their HQL transformers, and those queries should have been updated too.

The query was changed the whole BaseOBObject in the first position of the result array, instead of including just its id.

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

Fri, 13 Mar 2015 17:39:41 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Fri, 13 Mar 2015 17:39:41 +0000] rev 26180
CI: merge back from main

Fri, 13 Mar 2015 17:21:52 +0000CI: update AD_MODULE to version 26177
RM packaging bot <staff.rm@openbravo.com> [Fri, 13 Mar 2015 17:21:52 +0000] rev 26179
CI: update AD_MODULE to version 26177

Fri, 13 Mar 2015 14:32:45 +0100Related to issue 29201: reveting the commit. This change should be included in q3 (not in q2)
Naiara Martinez <naiara.martinez@openbravo.com> [Fri, 13 Mar 2015 14:32:45 +0100] rev 26178
Related to issue 29201: reveting the commit. This change should be included in q3 (not in q2)

Fri, 13 Mar 2015 11:57:34 +0100Fixed bug 28999:It's failing access to defined parent buttons in 2th-3th level
Inigo Sanchez <inigo.sanchez@openbravo.com> [Fri, 13 Mar 2015 11:57:34 +0100] rev 26177
Fixed bug 28999:It's failing access to defined parent buttons in 2th-3th level

The problem was related to the previous changes. It had added a wrong condition
that prevented a good behaviour in all cases. The wrong condition is:
"if (!view.parentView && button.view.actionToolbarButtons.containsProperty('property', button.property)) {"

Now, it have been resolved all problems by removing the part of the condition
that checks if a view is parent or not. There was no sense.

Fri, 13 Mar 2015 02:17:21 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Fri, 13 Mar 2015 02:17:21 +0000] rev 26176
CI: merge back from main

Fri, 13 Mar 2015 01:44:08 +0000CI: update AD_MODULE to version 26172
RM packaging bot <staff.rm@openbravo.com> [Fri, 13 Mar 2015 01:44:08 +0000] rev 26175
CI: update AD_MODULE to version 26172

Thu, 12 Mar 2015 16:06:00 +0100related to issue 29197 update Copyright
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 12 Mar 2015 16:06:00 +0100] rev 26174
related to issue 29197 update Copyright

Thu, 12 Mar 2015 16:00:40 +0100Fixed bug 29197 Payment Out is registered as "BP Deposit" transaction
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 12 Mar 2015 16:00:40 +0100] rev 26173
Fixed bug 29197 Payment Out is registered as "BP Deposit" transaction

In FIN_TransactionProcess.java set the correct value depending on
the type of transaction

Mon, 09 Mar 2015 18:58:14 +0100Fixes bug 29172: Improved performance select/deselect all records in OrderInv grid
Unai Martirena <unai.martirena@openbravo.com> [Mon, 09 Mar 2015 18:58:14 +0100] rev 26172
Fixes bug 29172: Improved performance select/deselect all records in OrderInv grid

The problem was that on every selection/deselection of a record in Order Invoices grid it was triggering the execution of these three methods: 'OB.APRM.AddPayment.updateInvOrderTotal(view.theForm, orderInvoice), OB.APRM.AddPayment.updateActualExpected(view.theForm), OB.APRM.AddPayment.updateDifference(view.theForm)'.
Actually it is not necessary to execute these functions on every record, because in the end they are updating total values, so just executing them after the iteration of the last record selected/deselected it would be enough.
To implement this, 'userSelectAllRecords' and 'deselectAllRecords' ListGrid methods have been overriden, to set a flag to true, in order to know when a record is changed while clicking selected/deselect all records, and in this case the three methods will be executed in the last record of the grid.
The 'OB.APRM.AddPayment.userSelectAllRecords' is executed only when clicking in select all records checkbox, but 'OB.APRM.AddPayment.deselectAllRecords' is executed while unchecking the previous checkbox and when fetching data in the grid using 'invalidateCache()' method. In this last case these functions will not be executed on every deselection neither in the last record, because they are already invoked directly in 'invalidateCache()', so in this case they will be avoided.

Thu, 12 Mar 2015 16:09:45 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Thu, 12 Mar 2015 16:09:45 +0000] rev 26171
CI: merge back from main

Thu, 12 Mar 2015 15:48:01 +0000CI: update AD_MODULE to version 26165
RM packaging bot <staff.rm@openbravo.com> [Thu, 12 Mar 2015 15:48:01 +0000] rev 26170
CI: update AD_MODULE to version 26165

Tue, 03 Mar 2015 12:04:20 +0100Related to issue 27953: Updated Copyright
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 03 Mar 2015 12:04:20 +0100] rev 26169
Related to issue 27953: Updated Copyright

Updated Copyright dates

Tue, 17 Feb 2015 12:33:34 +0100Fixed issue 27953 AccessibleOrgTree wrongly used in some reports
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 17 Feb 2015 12:33:34 +0100] rev 26168
Fixed issue 27953 AccessibleOrgTree wrongly used in some reports

In many manual reports the organization combo is filled using:

ComboTableData comboTableData = new ComboTableData(vars, this,
"TABLEDIR", "AD_ORG_ID", "", "", Utility.getContext(this, vars,
"#AccessibleOrgTree", "XXXX"), Utility.getContext(this, vars,
"#User_Client", "XXXX"), '*');

“#AccessibleOrgTree” context gets the list of all the granted organizations,
their ancestors and their descendants organizations. It's necessary to use
“#User_Org” instead, which contains the organizations that are granted
by the role:

ComboTableData comboTableData = new ComboTableData(vars, this,
"TABLEDIR", "AD_ORG_ID", "", "", Utility.getContext(this, vars,
"#User_Org", "XXXX"), Utility.getContext(this, vars,
"#User_Client", "XXXX"), '*');

Reports from these folders had been checked:
src/org/openbravo/erpCommon/ad_reports
src/org/openbravo/erpReports

Files affected by this issue had been changed and tried

Thu, 12 Mar 2015 12:00:30 +0100Fixes issue 29248: 0 can be used to filter numeric columns
Augusto Mauch <augusto.mauch@openbravo.com> [Thu, 12 Mar 2015 12:00:30 +0100] rev 26167
Fixes issue 29248: 0 can be used to filter numeric columns

In this changeset [1] this code was added to the OBNumberItem.parseValueExpressions function:

ret = this.Super('parseValueExpressions', [value, fieldName, operator]);
+
+ // if operator is not supported remove it
+ if (!this.validOperators.contains(ret.operator)) {
+ ret.operator = '';
+ ret.value = '';
+ this.setValue('');
+ }
if (ret && ret.start) {
ret.start = this.convertToTypedValue(ret.start);
}

The problem is that if the provided value is 0, this.Super('parseValueExpressions', [value, fieldName, operator]) will return undefined. This happens because of a bug in smartclient's implementation of the
parseValueExpressions function. This code is placed at the beginning of that function:

if (!value) value = this.getValue();
if (!value) return;
if (!isc.isA.String(value)) value += "";

If the provided value is 0, the value will be taken from this.getValue(). The returned value will again be evaluated to false, so the function will not return any value. Right after that, there is a comman
d to convert the provided value to String.

To fix this, in the call to this.Super('parseValueExpressions'), the string representation of the number will be passed instead of its numerical value. This way smartclient will accept the value and will n
ot return undefined. Smartclient was already converting the passed values to String, so there is no risk there.

The value passed to the OBNumberItem.parseValueExpressions is not modified to prevent unexpected consequences. A copy of it is converted to string and passed to the this.Super('parseValueExpressions') func
tion.

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

Thu, 12 Mar 2015 10:39:35 +0100Fixes issue 29092: Inconsistent data is not shown in the form view
Augusto Mauch <augusto.mauch@openbravo.com> [Thu, 12 Mar 2015 10:39:35 +0100] rev 26166
Fixes issue 29092: Inconsistent data is not shown in the form view

This issue was reproduced in the following scenario:
- A subtab is open in form view
- A change is done in its parent tab. That change (either through an event handler or through a trigger) deletes the record selected in the subtab and creates a new one
- The subtab is automatically refreshed. When the tab is refreshed:
* The whole grid is reloaded, it now contains all the current records
* The form view is shown again, and it tries to obtain the updated records from the grid. As the record selected in the form view is not present in the grid, the form view contains the old values

To fix this, when the record that was selected in the form view is no longer contained in the grid after the tab is refreshed, the form view is not shown. This was the grid view will be visible, and it will show the updated info.

Wed, 11 Mar 2015 13:23:31 +0100Related to issue 29110: Added a clear inside the loop
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 11 Mar 2015 13:23:31 +0100] rev 26165
Related to issue 29110: Added a clear inside the loop

Added a clear inside the loop to avoid performance problems

Wed, 11 Mar 2015 11:48:22 +0530Fixes Issue 29110:It is not possible to change currency in header tab in G/L
Atul Gaware <atul.gaware@openbravo.com> [Wed, 11 Mar 2015 11:48:22 +0530] rev 26164
Fixes Issue 29110:It is not possible to change currency in header tab in G/L
Journal

As there is trigger mutating error, updation of gl journal line currency and
currency rate is moved to a event handler from gl_journal_trg trigger.

Wed, 11 Mar 2015 15:19:41 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Wed, 11 Mar 2015 15:19:41 +0000] rev 26163
CI: merge back from main