Thu, 04 Aug 2016 09:52:25 -0400Fixes issue 33560: Error voiding an invoice if bp doesn't have default account
Mark <markmm82@gmail.com> [Thu, 04 Aug 2016 09:52:25 -0400] rev 29965
Fixes issue 33560: Error voiding an invoice if bp doesn't have default account

Method used to get the default financial account (getFinancialAccountPaymentMethod) was not taking into account the natural tree of the organization of document being processed, always was ordering by "default" account and when the query returns more than one results, if the first record's account does not belong to the natural tree of the entity's organization (in this case invoice's organization) validation was failing and an error message was shown.

To avoid it, was overwritten the getFinancialAccountPaymentMethod method of the FIN_Utility class to also filtering by financial accounts belonging to the natural tree of the entity's organization. Was necessary to adapt other classes using this method to work correctly.

Wed, 31 Aug 2016 13:10:56 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Wed, 31 Aug 2016 13:10:56 +0000] rev 29964
CI: merge back from main

Wed, 31 Aug 2016 12:56:56 +0000CI: update AD_MODULE to version 29953
RM packaging bot <staff.rm@openbravo.com> [Wed, 31 Aug 2016 12:56:56 +0000] rev 29963
CI: update AD_MODULE to version 29953

Tue, 30 Aug 2016 09:12:33 +0200Related to issue 32967, Related to issue 33033: Fixed dbcons
Ander Iraceburu <ander.iraceburu@openbravo.com> [Tue, 30 Aug 2016 09:12:33 +0200] rev 29962
Related to issue 32967, Related to issue 33033: Fixed dbcons

Tue, 30 Aug 2016 09:08:07 +0200Fixed issue 32967: Funds transfer development
Ander Iraceburu <ander.iraceburu@openbravo.com> [Tue, 30 Aug 2016 09:08:07 +0200] rev 29961
Fixed issue 32967: Funds transfer development

Mon, 29 Aug 2016 12:11:38 +0200Fixed issue 33033: Cost center in trial balance development
Ander Iraceburu <ander.iraceburu@openbravo.com> [Mon, 29 Aug 2016 12:11:38 +0200] rev 29960
Fixed issue 33033: Cost center in trial balance development

Wed, 31 Aug 2016 12:22:30 +0200Fixed issue 33750.Add new methods in SessionHandler to manage transactions.
Gorka Ion Damián <gorkaion.damian@openbravo.com> [Wed, 31 Aug 2016 12:22:30 +0200] rev 29959
Fixed issue 33750.Add new methods in SessionHandler to manage transactions.

Two new public methods added:
- isCurrentTransactionActive()
- beginNewTransaction()

These methods are needed to be able to modify the database in EventHandlers
that are fired when the transaction is completed.

Wed, 31 Aug 2016 12:19:24 +0200Backed out changeset 4ece62a0e09c
Gorka Ion Damián <gorkaion.damian@openbravo.com> [Wed, 31 Aug 2016 12:19:24 +0200] rev 29958
Backed out changeset 4ece62a0e09c

Wed, 31 Aug 2016 11:42:06 +0200Fixed issue 33750.Add new methods in SessionHandler to manage transactions.
Gorka Ion Damián <gorkaion.damian@openbravo.com> [Wed, 31 Aug 2016 11:42:06 +0200] rev 29957
Fixed issue 33750.Add new methods in SessionHandler to manage transactions.

Two new public methods added:
- isCurrentTransactionActive()
- beginNewTransaction()

These methods are needed to be able to modify the database in EventHandlers
that are fired when the transaction is completed.

Wed, 31 Aug 2016 11:25:47 +0200Related to issue 33771: Remove setMaxResults(1)
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 31 Aug 2016 11:25:47 +0200] rev 29956
Related to issue 33771: Remove setMaxResults(1)

setMaxResults(1) is not needed as we are filtering by unique constraint.

Wed, 31 Aug 2016 11:11:13 +0200Related to issue 33771: Code review improvements
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 31 Aug 2016 11:11:13 +0200] rev 29955
Related to issue 33771: Code review improvements

Use uniqueResult() == null instead of list().isEmpty(), adding setMaxResults(1) to avoid exceptions.
Update copyright.

Mon, 29 Aug 2016 15:25:51 +0200Fixed issue 33601: Preferences.getPreferenceValue's performance improved
Naroa Iriarte <naroa.iriarte@openbravo.com> [Mon, 29 Aug 2016 15:25:51 +0200] rev 29954
Fixed issue 33601: Preferences.getPreferenceValue's performance improved

There are two methods called Preferences.getPrferenceValue. Before, one of them was getting the Client, org... objects and passing them as arguments to the other function. The other function was getting the Id from those objects to execute all the logic. This was not a good code, because one function was making queries to the database to get the objects just to pass them as arguments of the other function and in that funtion, those objects were only used to get the Id... so it has been modifyied. Now the function which before was called in the other is the one which calls the other function. Thanks to this change it is not needed to query the database to get the client, organization, user, role and window objects.

Wed, 31 Aug 2016 10:27:37 +0200related to issue 33775: backed out changes
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 31 Aug 2016 10:27:37 +0200] rev 29953
related to issue 33775: backed out changes

Backed out changes as the problem is still reproducible

Wed, 31 Aug 2016 08:37:02 +0200related to issue 33622: added javadoc to explain how the new methods work
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 31 Aug 2016 08:37:02 +0200] rev 29952
related to issue 33622: added javadoc to explain how the new methods work

Tue, 30 Aug 2016 12:34:23 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 30 Aug 2016 12:34:23 +0000] rev 29951
CI: merge back from main

Tue, 30 Aug 2016 12:20:31 +0000CI: update AD_MODULE to version 29949
RM packaging bot <staff.rm@openbravo.com> [Tue, 30 Aug 2016 12:20:31 +0000] rev 29950
CI: update AD_MODULE to version 29949

Tue, 30 Aug 2016 09:49:50 +0200Related with issue 33073: The JSONWebServicesWhereParameter test improved
Naroa Iriarte <naroa.iriarte@openbravo.com> [Tue, 30 Aug 2016 09:49:50 +0200] rev 29949
Related with issue 33073: The JSONWebServicesWhereParameter test improved

This test has been improvet to avoid null pointer exceptions in the case of not getting any data in the response.

Mon, 29 Aug 2016 19:01:36 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 29 Aug 2016 19:01:36 +0000] rev 29948
CI: merge back from main

Mon, 29 Aug 2016 18:47:48 +0000CI: update AD_MODULE to version 29946
RM packaging bot <staff.rm@openbravo.com> [Mon, 29 Aug 2016 18:47:48 +0000] rev 29947
CI: update AD_MODULE to version 29946

Tue, 16 Aug 2016 14:44:35 -0400Fixes issue 33666: Zero amount instead of withdrawal amount in Add Payment
Nono Carballo <nonofce@gmail.com> [Tue, 16 Aug 2016 14:44:35 -0400] rev 29946
Fixes issue 33666: Zero amount instead of withdrawal amount in Add Payment

When creating a payment out with Add Payment process in Financial Account window (from Transaction tab or Match Statement | Add Transaction process), actual payment will be loaded with withdrawal amount.
If transaction withdrawal amount is different than 0, actual payment will be loaded with withdrawal amount but will not be distributed into order/invoices in the grid. If total amount is lower than withdrawal amount, actual payment will not be updated with total amount and we will be able to leave the difference between withdrawal amount and total amount as credit. If total amount is higher than withdrawal amount, actual payment will be updated with total amount and we will be able to pay more amount than withdrawal amount.
If transaction withdrawal amount is 0, actual payment will always be updated with total amount and it will not be possible to generate credit in this payment.

We have reverted changes done in ob-aprm-addPayment.js for issues 33465 and 31392, and we will retrieve bslamount as deposit amount - withdrawal amount also in Transaction tab, as it is done in Add Transaction process.
With this, opening Add Payment from both Transaction tab and Add Transaction process, will have the same behavior as it used to when opening from Add Transaction process in 16Q1 (before fixing issue 31392).

Mon, 29 Aug 2016 11:18:05 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 29 Aug 2016 11:18:05 +0000] rev 29945
CI: merge back from main

Mon, 29 Aug 2016 11:04:15 +0000CI: update AD_MODULE to version 29941
RM packaging bot <staff.rm@openbravo.com> [Mon, 29 Aug 2016 11:04:15 +0000] rev 29944
CI: update AD_MODULE to version 29941

Mon, 29 Aug 2016 11:24:40 +0200fixes issue 33775: Create New is not working with saved views marked as default
Carlos Aristu <carlos.aristu@openbravo.com> [Mon, 29 Aug 2016 11:24:40 +0200] rev 29943
fixes issue 33775: Create New is not working with saved views marked as default

When using Create New menu entry to create a new record in a window that has a saved view marked as default, the form was being opened before the loading of the saved view, causing the problem.

To fix it, now the opening of the form is deferred until the window is loaded (including the load of the saved views, if any).

Tue, 23 Aug 2016 16:15:02 +0200Fixed issue 32153: Update Characteristic process was not working fine
Naroa Iriarte <naroa.iriarte@openbravo.com> [Tue, 23 Aug 2016 16:15:02 +0200] rev 29942
Fixed issue 32153: Update Characteristic process was not working fine

There were 4 request to create datasources for each characteristic, this was happening on one hand because there were two calls to the super and also because call to OB.Datasource.get() was being executed in two different places. Removing the duplicated super fixed part of the problem, to fix the other part, now a condition has been added in the ob-tree-item class. This condition checks if there is a concrete property (showPopupIconWindow) set to false. If it is set to false the magnifying glass icon will not be created and the OBTreeItemPopupWindow neither, so the uneeded call to the OB.Datasource.get() will not be done.
There was another problem also, if the dropdown of a characteristic was clicked before the creation of the datasource, it was showing the message "No items to show" and a js error in the console. To fix this, a condition has been added. The condition checks if there exists a datasource and clicking the dropdown will not work until a datasource exist.

Fri, 26 Aug 2016 09:49:28 +0200Fixed issue 32020: code review improvements
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 26 Aug 2016 09:49:28 +0200] rev 29941
Fixed issue 32020: code review improvements

+ Allow partial match for multiple transactions as we allow for single transactions
+ Use adminMode when necessary
+ Code and javadoc improvements
+ Improved partial match message from add transaction and find transaction
+ Matching level properly passed to matchBankStatementLineToTrx() method.

Tue, 05 Jul 2016 13:54:52 +0530Fixed issue 32020: [Match Several Transactions Project]
Atul Gaware <atul.gaware@openbravo.com> [Tue, 05 Jul 2016 13:54:52 +0530] rev 29940
Fixed issue 32020: [Match Several Transactions Project]

Allow to match several transactions against a concrete bank statement line

Sat, 27 Aug 2016 12:47:43 +0200Backed out changeset: d538bed5bf3b, Fix nextLine. Remove rogue commit
Rafa Alonso <ral@openbravo.com> [Sat, 27 Aug 2016 12:47:43 +0200] rev 29939
Backed out changeset: d538bed5bf3b, Fix nextLine. Remove rogue commit

Sat, 27 Aug 2016 12:22:15 +0200Fix nextLine
Rafa Alonso <ral@openbravo.com> [Sat, 27 Aug 2016 12:22:15 +0200] rev 29938
Fix nextLine

Fri, 26 Aug 2016 16:01:09 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Fri, 26 Aug 2016 16:01:09 +0000] rev 29937
CI: merge back from main

Fri, 26 Aug 2016 15:47:16 +0000CI: update AD_MODULE to version 29935
RM packaging bot <staff.rm@openbravo.com> [Fri, 26 Aug 2016 15:47:16 +0000] rev 29936
CI: update AD_MODULE to version 29935