Thu, 04 Dec 2014 09:59:46 +0000Update AD_MODULE version to 3.0PR14Q3.4
RM packaging bot <staff.rm@openbravo.com> [Thu, 04 Dec 2014 09:59:46 +0000] rev 24105
Update AD_MODULE version to 3.0PR14Q3.4

Tue, 25 Nov 2014 12:08:01 +0100Fixed issue 28242: Load grid even with inconsistent default view info
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 25 Nov 2014 12:08:01 +0100] rev 24104
Fixed issue 28242: Load grid even with inconsistent default view info

Before the previous changeset was applied, it was possible to have a preference that specified that a certain grid had a default saved view, but that the referenced default saved view did not actually exists. When this happened the grid was not loaded until the user pressed the Refresh button.

To fix this, now the inconsistent default view info is detected and the grid is loaded once it is detected that the default view does not actually exists.

Tue, 25 Nov 2014 11:51:55 +0100Related with issue 28242: Delete preference along with window personalization
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 25 Nov 2014 11:51:55 +0100] rev 24103
Related with issue 28242: Delete preference along with window personalization

When a grid view is saved and set as default two records are added:
- One to the OBUIAPP_UIPersonalization with the description of the view
- One to the Preference table, using the OBUIAPP_DefaultSavedView property, whose value is the ID of the record added to the OBUIAPP_UIPersonalization table

The problem of this issue was that when the a default saved view was removed from the OBUIAPP_UIPersonalization table, its corresponding entry from the Preference table was not removed. This resulted in not making the initial request to load the grid because it was detected that the view had a default saved view (using the preference), and not doing it after loading the window personalization because the view description was removed from OBUIAPP_UIPersonalization.

The first step of the issue, included in this changeset, removes the Preference associated with a default saved view when it is deleted from OBUIAPP_UIPersonalization. This prevents the data from being inconsistent. The second and final step will consist in loading the grid even when the data is inconsistent, to fix the cases where the data is already inconsistent.

Wed, 03 Dec 2014 20:26:01 +0530Fixes Issue 28236: Payment schedule amount incorrectly calculated.
Pandeeswari Ramakrishnan <pandeeswari.ramakrishnan@openbravo.com> [Wed, 03 Dec 2014 20:26:01 +0530] rev 24102
Fixes Issue 28236: Payment schedule amount incorrectly calculated.

Payment schedule amount incorrectly calculated when adding a payment from reconcile window to a sales order

Mon, 24 Nov 2014 20:20:57 +0530Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation
Atul Gaware <atul.gaware@openbravo.com> [Mon, 24 Nov 2014 20:20:57 +0530] rev 24101
Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation
referencing a cash vat invoice linked to several orders

Issue is a regression due to related fix for issue 26571. Cast Vat lines
were posted as many times the no. of orders linked with cash vat invoices.
So now posting is based on the payment details so the relevant cash vat line
associated with it is posted though it is looped as many times as the no. of
orders linked.

Wed, 19 Nov 2014 18:09:26 +0100Fixes issue 28229: Lazy Filtering works properly in P&E windows
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Nov 2014 18:09:26 +0100] rev 24100
Fixes issue 28229: Lazy Filtering works properly in P&E windows

There was a problem when the button to apply the current filters (only shown when lazy filtering is configured for a tab) was pressed in a P&E window. If the filters were not changed before pressing the button, the grid.refreshGrid function was invoked, and this function was not defined for P&E windows. This function has been defined now. Also, a flag has been added to detect when the filterClause is removed, to allow refreshing the grid in that case even if the filter editor is not changed.

Thu, 20 Nov 2014 11:48:06 +0530Fixes Issue 28226:Is not possible to Void a shipment related with an order
Atul Gaware <atul.gaware@openbravo.com> [Thu, 20 Nov 2014 11:48:06 +0530] rev 24099
Fixes Issue 28226:Is not possible to Void a shipment related with an order
and containing a negative line

A check to avoid MovementQtyCheck for Reversed Document is provided.

Tue, 18 Nov 2014 22:10:10 +0100Fixes issue 28214: _selectedProperties parameter work in JSON REST webservice
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 18 Nov 2014 22:10:10 +0100] rev 24098
Fixes issue 28214: _selectedProperties parameter work in JSON REST webservice

In a call to the Openbravo JSON REST webservice, the _selectedProperties parameter allows the user to specify the set of properties whose values should be returned by the webservice. This property was working properly when an ID is specified in the request, but not if it is not specified.

This stopped working because of this issue [1]. [1] implements a new method to handlle the case when the ID is not specified to improve the performance, but its missing the handling of _selectedProperties.

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

Tue, 18 Nov 2014 18:43:55 +0100Fixes bug 28220:FK no longer filtered without applying selected parent criteria
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 18 Nov 2014 18:43:55 +0100] rev 24097
Fixes bug 28220:FK no longer filtered without applying selected parent criteria

The problem was the following. If a tab was configured to use lazy filtering, when one of its foreign keys is filtered the criteria is obtained from the current values of the filter editor, instead of directly calling the getCriteria function of the grid.

The problem is that the criteria was not being passed to the OBViewGrid.convertCriteria function, which among other things adds the criteria to filter by the record selected in the parent tab. The result was that the dropdown contained way more records than it should, and that the query to retrieve the records could have very bad performance if the table associated with the tab contained many records.

Wed, 19 Nov 2014 10:40:03 +0100Fixes issue 28212: Prevent NPE in FormatUtilities.replaceJS
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 19 Nov 2014 10:40:03 +0100] rev 24096
Fixes issue 28212: Prevent NPE in FormatUtilities.replaceJS

In this changeset [1] the FormatUtilities.replaceJS was updated to make it secure against cross site scripting. The problem was that before the change the method returned null if the strIni parameter is null, but after the change a NullPointerException is thrown. Added a check to prevent this.

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