Wed, 22 Apr 2015 16:57:29 +0200Fixed issue 29064:There are problems with the organization of the notes.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Wed, 22 Apr 2015 16:57:29 +0200] rev 26338
Fixed issue 29064:There are problems with the organization of the notes.

There were two problems:
First: When a note was created, it had context organization instead of document organization.
To fix this, a new field which stores the note's organization has been created in the "ob-view-form-notes.js".
Second: If a note was added with an organization and after that the organization of the note
was changed, there were problems to handle it.
A new manual datasource has been created for handling the fetch,add and remove operations of the notes,
making sure that the organization filter is disabled. So, we grant the fact that if a user of one
organization creates a note and after that the organization of the note is changed to another one which
the user has not access, the user will be able to see or delete the note.

Tue, 21 Apr 2015 14:18:22 +0200Fixed bug 29653: Payment selector now filters by child organizations
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Tue, 21 Apr 2015 14:18:22 +0200] rev 26337
Fixed bug 29653: Payment selector now filters by child organizations

The payment selector was incorrectly filtering by child organizations because the order of the parameters in the call to the AD_ISORGINCLUDED function was wrong.

It now gets all the payments belonging to the organization and any child organization of the tab's organization.

Wed, 22 Apr 2015 10:46:09 +0200fixes issue 29554: Date filters not cleared when switching between saved views
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 22 Apr 2015 10:46:09 +0200] rev 26336
fixes issue 29554: Date filters not cleared when switching between saved views

The problem was that the clearValue() method of FormItem is not enough to clear the contents of the filter.
To solve it the clearValue method of OBMiniDateRangeItem has been overriden.
Also, it was necessary to call setValue() inside the displayValue() method, to set the value of the object and avoid the clearing of the dates in the filter when smartclient invokes the setItemValues() method of the form.

Fri, 27 Feb 2015 14:42:02 +0100Fixed issue 28867:It isn't possible to create Menu Items from Widget instances
Naroa Iriarte <naroa.iriarte@openbravo.com> [Fri, 27 Feb 2015 14:42:02 +0100] rev 26335
Fixed issue 28867:It isn't possible to create Menu Items from Widget instances

At first it was possible to create a new menu item entry if the selected Widget was a parent Widget,
but it was not possible if the current widget was an instance of a parent Widget.
For example if you create a new entry in the Query/List widget it wold be possible and it would show in
the Menu Item list of any instance of that Widget. But if you choose a concrete widget which has a
superclass of the type Query/List, and create a new menu item, it would be not possible to display it in the widget.

As it was interesting to be able to add a menu item at widget instance level, the logic which handled this has been changed.
Now it takes into account if the instanciated widget has a menu item.

It is only possible to add functionality to those item menus with functions defined in the OBWidget.js

Tue, 21 Apr 2015 11:04:04 +0200Fixes issue 29605: Foreign currency not setted in transaction
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 21 Apr 2015 11:04:04 +0200] rev 26334
Fixes issue 29605: Foreign currency not setted in transaction

When creating a transaction manually from a payment, foreign currency, foreign conversion rate and foreign amount fields were not setted to transaction. Now, they will be setted as in TransactionDao.java, when the transaction is automatically created from the payment.

Tue, 21 Apr 2015 11:16:53 +0530Fixes Issue 29509:Process Price Difference Adjustment is not working properly.
Atul Gaware <atul.gaware@openbravo.com> [Tue, 21 Apr 2015 11:16:53 +0530] rev 26333
Fixes Issue 29509:Process Price Difference Adjustment is not working properly.

Counter of the updated transaction is calculated based on Cost Adjustment
creation and not on the basis of updating
PriceDifferenceAdjustment flag = Yes

Mon, 20 Apr 2015 14:19:07 +0200Related issue 28190: Failing to drop the database will cause the build to fail (II)
Rafa Alonso <rafael.alonso@openbravo.com> [Mon, 20 Apr 2015 14:19:07 +0200] rev 26332
Related issue 28190: Failing to drop the database will cause the build to fail (II)

After Stefan feedback:
- the fix now makes use of the existing DROP in the "clean.database.POSTGRE" task. The change is that the build will but the build fail if the drop fails.
- the "clean.database.POSTGRE" task is being accessed by the <target name="create.database"> task.

Note that the "clean.database.ORACLE" task has not been in this changeset.

Fri, 17 Apr 2015 14:56:13 +0200Fixes bug 29615: Correctly used credit when paying an invoice and refunding
Unai Martirena <unai.martirena@openbravo.com> [Fri, 17 Apr 2015 14:56:13 +0200] rev 26331
Fixes bug 29615: Correctly used credit when paying an invoice and refunding

There were two issues while managing this scenario:

[1] In 'addCredit' method inside AddPaymentActionHandler.java class, a loop of Credit to Use grid is done, creating Payment Credit Used records assigned to the new created payment of the invoice. This method was not taking into account that could be credit amount that exceeds the invoice amount (amount to be refunded) and it was assigning all the credit amount as used to the payment of the invoice. So the refund payment that is created right after was been left without any used credit payment.

[2] After fixing the previous method, the second issue appears. The 'updateUsedCredit' method inside FIN_PaymentProcess.java class retrieves all the payments of the business partner that has generated credit, and it assigns as used to the refund payment. The problem with this function is that before the Add Payment refactor it was not possible to select which credit payments we wanted to consume, it was only a total credit amount to be consumed and the system behind was being consuming any of them. But after the refactor it is possible to select the ones that want to be consumed.

In order to fix this last issue the selected credit line ids are added as a parameter to 'updateUsedCredit' method.

Fri, 17 Apr 2015 11:10:36 +0200fixes issue 29373: Property fields can overwrite values in request of the FIC
Carlos Aristu <carlos.aristu@openbravo.com> [Fri, 17 Apr 2015 11:10:36 +0200] rev 26330
fixes issue 29373: Property fields can overwrite values in request of the FIC

The FIC could overwrite the values of some fields having a property field in the same tab referencing a column with the same name.
To solve this problem now the setRequestContextParameter() stores in the request de correct name for the parameter related to the property field

Fri, 17 Apr 2015 12:31:27 +0200Fixed bug 29607: setup application is not taking into account the context name
Inigo Sanchez <inigo.sanchez@openbravo.com> [Fri, 17 Apr 2015 12:31:27 +0200] rev 26329
Fixed bug 29607: setup application is not taking into account the context name

The setup application is not taking into account the context name that users
are configuring. The values of "deploy-name" and "context-root" properties
of org.eclipse.wst.common.component are not updating.

Now it has been solved and if user set "context-name" in setup application.
this value is updating in org.eclipse.wst.common.component. For example if
a user set the context name as "test" the URL to go to Openbravo is
"http://localhost:8080/test" instead of default one "http://localhost:8080/openbravo".