Tue, 17 Mar 2015 18:48:37 +0100Fixed bug 29147: Used credit is not correct under certain circumstances
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 17 Mar 2015 18:48:37 +0100] rev 26242
Fixed bug 29147: Used credit is not correct under certain circumstances

Mon, 16 Mar 2015 18:49:22 +0100Fixes bug 29294: valueMap and value of combo item is properly set in P&E window
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 18:49:22 +0100] rev 26241
Fixes bug 29294: valueMap and value of combo item is properly set in P&E window

There were two things missing in the previous fix:
- The attribute names of the valueMap were not proper
- The value of the combo item should be set after defining its valueMap, otherwise the value is lost

Thu, 12 Mar 2015 10:54:39 +0100Fixed bug 29150 improve performance in UpdatePaymentPlan modulescript
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 12 Mar 2015 10:54:39 +0100] rev 26240
Fixed bug 29150 improve performance in UpdatePaymentPlan modulescript

Mon, 16 Mar 2015 16:57:41 +0100Fixes issue 29294: valueMap is properly initialized in pick and execute windows
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 16:57:41 +0100] rev 26239
Fixes issue 29294: 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 17:22:59 +0100Related with issue 29294: Checks if the okButton exists to prevent error in log
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 17:22:59 +0100] rev 26238
Related with issue 29294: Checks if the okButton exists to prevent error in log

Fri, 13 Mar 2015 13:00:24 +0100Fixes bug 29265 Improved performance select/deselect all records in OrderInv grid
Unai Martirena <unai.martirena@openbravo.com> [Fri, 13 Mar 2015 13:00:24 +0100] rev 26237
Fixes bug 29265 Improved performance select/deselect all records in OrderInv grid

Thu, 12 Mar 2015 12:00:30 +0100Fixes issue 29254: 0 can be used to filter numeric columns
Augusto Mauch <augusto.mauch@openbravo.com> [Thu, 12 Mar 2015 12:00:30 +0100] rev 26236
Fixes issue 29254: 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

Wed, 11 Mar 2015 13:23:31 +0100Related to issue 29251: Added a clear inside the loop
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 11 Mar 2015 13:23:31 +0100] rev 26235
Related to issue 29251: 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 29251:It is not possible to change currency in header tab in G/L Journal
Atul Gaware <atul.gaware@openbravo.com> [Wed, 11 Mar 2015 11:48:22 +0530] rev 26234
Fixes Issue 29251: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.

Fri, 06 Mar 2015 08:10:31 +0100fixed issue 29156: added log on table recreation when updating database
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 06 Mar 2015 08:10:31 +0100] rev 26233
fixed issue 29156: added log on table recreation when updating database

Mon, 23 Feb 2015 17:10:34 +0100Fixed issue 29021 It is possible to process Payment Out without set amount
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 23 Feb 2015 17:10:34 +0100] rev 26232
Fixed issue 29021 It is possible to process Payment Out without set amount

Added a new validation in process button because it is not possible
to add a glitem with both amounts equal to 0.
Added a default value in received in and paid out fields in glitem
grid.

Mon, 23 Feb 2015 18:52:28 +0100Fixes issue 29029: SL_Journal_Period raises a NullPointer Exception
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 23 Feb 2015 18:52:28 +0100] rev 26231
Fixes issue 29029: SL_Journal_Period raises a NullPointer Exception

AcctSchema will be retrieved only if acctSchemaId is not null (G/L Journal Header tab). In other case (G/L Journal Batch tab) it will not.

Tue, 24 Feb 2015 22:16:04 +0100Fixes issue 29010: Grid is actually filtered using relative dates
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 24 Feb 2015 22:16:04 +0100] rev 26230
Fixes issue 29010: Grid is actually filtered using relative dates

The problem was that when a relative date filter was added to the grid and then used in a saved view, the saved view will not apply the relative date filter, but an absolute one. This was caused by this code in the OBViewGrid.convertCriteria function:

if (this.dataSource) {
criteria = this.dataSource.convertRelativeDates(criteria);
}

Every time that a criteria is sent to the backend (i.e. when storing a saved view), the criteria objects that contained relative dates wwere converted to absolute dates. This was done to fix this issue
[1], its problem being that the datasource used to populate the filter drop down did not support relative dates.

The function where that code was placed was too central, the criterias converted should have been only the ones used to populate the filter drop downs, but all the criterias were being converted. To fix this, the code has been adapted and moved to the OBFKFilterTextItem.getPickListFilterCriteria function.
[1] https://issues.openbravo.com/view.php?id=27679

Tue, 24 Mar 2015 02:43:40 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Mar 2015 02:43:40 +0000] rev 26229
CI: merge back from main

Tue, 24 Mar 2015 02:28:46 +0000CI: update AD_MODULE to version 26226
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Mar 2015 02:28:46 +0000] rev 26228
CI: update AD_MODULE to version 26226

Mon, 23 Mar 2015 21:55:29 +0100Fixed issue 29066: Process definition should inherit permissions from window
Inigo Sanchez <inigo.sanchez@openbravo.com> [Mon, 23 Mar 2015 21:55:29 +0100] rev 26227
Fixed issue 29066: Process definition should inherit permissions from window

The problem was that in some cases when a rol had access to a window, he
did not have access to the processes of the window. The problem was when a
proccess was referenced by a OBUISEL_Selector reference.

This problem happens when is controlled access process. In many cases the
windowId is null.

Now, this problem has been solved because windowId will have a value.

Mon, 23 Mar 2015 17:27:10 +0100Related to issue 29162: Make code more clear
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 23 Mar 2015 17:27:10 +0100] rev 26226
Related to issue 29162: Make code more clear

Mon, 23 Mar 2015 17:05:15 +0100Related to issue 29162: Update copyright
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 23 Mar 2015 17:05:15 +0100] rev 26225
Related to issue 29162: Update copyright

Wed, 18 Mar 2015 16:47:06 -0500Fixed bug 29162: Add Transaction process does not consider well amounts of 0.00
Reinaldo Guerra <reinaldo.guerra@peoplewalking.com> [Wed, 18 Mar 2015 16:47:06 -0500] rev 26224
Fixed bug 29162: Add Transaction process does not consider well amounts of 0.00

The "compareTo" method was taken into account instead of "equals", to compare BigDecimal.ZERO value with 0.00 (a BigDecimal value with a scale), inside AddTransactionFilterExpression class.
This change was made because BigDecimal "equals", compares the value and the scale, returning false when comparing 0 with 0.00, while "compareTo" only compares values, so considers amounts 0.00 and 0 as the same values. Now transaction type is correctly set to BP Deposit, when "dramount" field is set to 0.00.

Mon, 23 Mar 2015 17:22:40 +0100Related to bug 29315: Add copyright header
Unai Martirena <unai.martirena@openbravo.com> [Mon, 23 Mar 2015 17:22:40 +0100] rev 26223
Related to bug 29315: Add copyright header

Tue, 17 Mar 2015 13:03:33 +0100Fixes issue 29315: Wrong accounts when posting multi-general ledger G/L Journal
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 17 Mar 2015 13:03:33 +0100] rev 26222
Fixes issue 29315: Wrong accounts when posting multi-general ledger G/L Journal

When getting accounts from GL Item (while posting a Simple G/L Journal setted as multi-general ledger), they were setted wrongly to accounting lines

Mon, 23 Mar 2015 17:14:45 +0100Fixes bug 29374: Warehouse field of Manage Reservation P&E shows a proper value
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 23 Mar 2015 17:14:45 +0100] rev 26221
Fixes bug 29374: Warehouse field of Manage Reservation P&E shows a proper value

The is a bug in that P&E, reported here [1], that makes the FIC return the wrong value for the warehouse field of the Manage Reservation P&E window. Before [2] was fixed, [1] did not have any consequences, as the value returned by the FIC was not set to the row being edited.

To fix this, the values returned by the FIC are only set if the field is editable. [1] will have to be fixed anyway, because even if now it does not crete problems in this flow, it could be causing problems in others.

[1] https://issues.openbravo.com/view.php?id=29381
[2] https://issues.openbravo.com/view.php?id=28727

Mon, 23 Mar 2015 15:23:47 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 23 Mar 2015 15:23:47 +0000] rev 26220
CI: merge back from main

Mon, 23 Mar 2015 15:08:37 +0000CI: update AD_MODULE to version 26214
RM packaging bot <staff.rm@openbravo.com> [Mon, 23 Mar 2015 15:08:37 +0000] rev 26219
CI: update AD_MODULE to version 26214

Tue, 17 Mar 2015 11:56:11 +0100Fixes issue 29257: Avoid error when posting a multi-general ledger G/L Journal
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 17 Mar 2015 11:56:11 +0100] rev 26218
Fixes issue 29257: Avoid error when posting a multi-general ledger G/L Journal

General Ledger will be taken from G/L Item instead from Simple G/L Journal when it is marked as multi-general ledger, because in this case General Ledger from Simple G/L Journal will be empty

Mon, 23 Mar 2015 12:56:19 +0100related to issue 29252 update Copyright
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 23 Mar 2015 12:56:19 +0100] rev 26217
related to issue 29252 update Copyright

Mon, 16 Mar 2015 17:07:49 +0100Fixes bug 29252: Payment method in add payment does not display inactive values
Unai Martirena <unai.martirena@openbravo.com> [Mon, 16 Mar 2015 17:07:49 +0100] rev 26216
Fixes bug 29252: Payment method in add payment does not display inactive values

The whereClause of fin_payment_method combo in add payment has been changed to not display never payment methods that are inactive.

Also the default values of Add Payment window that are opened from all windows has been changed to not set as default a Payment Method that is inactive, even if it is marked as default in the financial account or if is the default payment method of the Business Partner.

A change has also been done in OB.APRM.AddPayment.paymentMethodMulticurrency javascript function. In Add Payment window, while clearing Payment Method combo manually, the Financial Account was also being cleared. This was causing a problem when opening from Financial Account, because in this case novalues were displayed on both combos any more. It has been fixed to not to clear the Financial Account combo in this case as always is going to be the same, so it is no necessary to clear it.

Mon, 23 Mar 2015 12:52:19 +0100Fixes issue 0029370: Exception in Purchase Invoice dimensional
Jon Alegría <jon.alegria@openbravo.com> [Mon, 23 Mar 2015 12:52:19 +0100] rev 26215
Fixes issue 0029370: Exception in Purchase Invoice dimensional
report, comparative option set

Wed, 11 Mar 2015 13:52:26 +0100Fixes bug 29073: InvoiceLine tax delete only is done when is needed
Unai Martirena <unai.martirena@openbravo.com> [Wed, 11 Mar 2015 13:52:26 +0100] rev 26214
Fixes bug 29073: InvoiceLine tax delete only is done when is needed

C_INVOICELINE_TRG2 has been changed to better manage when Invoice Line taxes are deleted and created again. Instead of doing it on every time an invoiceline is inserted or updated, it will be done when certain values in Invoice Line are changed and this affects in the related Invoice Line Tax record. The result will be the same, because with the previous code when there was no change in the Invoice Line the Invoice Line taxes were recreated with the same values as before, and now will be skipped.

Apart of this previous change, all not used variables have been removed, and in the same way a complete select sentence that was obtaining values that were not used later.

Fri, 20 Mar 2015 18:22:24 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Fri, 20 Mar 2015 18:22:24 +0000] rev 26213
CI: merge back from main