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

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 26175
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 26174
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

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 26173
CI: update AD_MODULE to version 26172

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

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 26170
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 26169
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 26168
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