Tue, 12 May 2015 17:53:41 +0200Adds new junit tests for accounting (PostDocumentTest)
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Tue, 12 May 2015 17:53:41 +0200] rev 26615
Adds new junit tests for accounting (PostDocumentTest)
Attend regressions for issues: 29266, 29403, 29505

Tue, 12 May 2015 15:38:15 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 12 May 2015 15:38:15 +0000] rev 26614
CI: merge back from main

Tue, 12 May 2015 15:22:57 +0000CI: update AD_MODULE to version 26612
RM packaging bot <staff.rm@openbravo.com> [Tue, 12 May 2015 15:22:57 +0000] rev 26613
CI: update AD_MODULE to version 26612

Mon, 11 May 2015 19:21:58 +0200Related to issue 29319: Performance Problems on the process of Validating a Costing Rule
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Mon, 11 May 2015 19:21:58 +0200] rev 26612
Related to issue 29319: Performance Problems on the process of Validating a Costing Rule
Some code refactoring after code review

Tue, 05 May 2015 13:26:14 +0200Fixes issue 29319: Performance problems validating a Costing Rule
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 05 May 2015 13:26:14 +0200] rev 26611
Fixes issue 29319: Performance problems validating a Costing Rule

Query in checkTransactionsWithMovDateInClosedPeriod method of CostingRuleProcessOnProcessHandler class, which has performance problems, has been changed.
Now M_Transaction.movementdate are truncated and grouped in order to have only one record per day instead of one record per transaction, which enhance a lot the performance of the query.
The query has been created in XSQL, because subquerys in FROM statement in HQL are not supported.

Mon, 11 May 2015 19:51:33 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 11 May 2015 19:51:33 +0000] rev 26610
CI: merge back from main

Mon, 11 May 2015 19:22:03 +0000CI: update AD_MODULE to version 26603
RM packaging bot <staff.rm@openbravo.com> [Mon, 11 May 2015 19:22:03 +0000] rev 26609
CI: update AD_MODULE to version 26603

Fri, 08 May 2015 13:13:33 +0200Fixes issue 29807: Warning message should be an Error message
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 08 May 2015 13:13:33 +0200] rev 26608
Fixes issue 29807: Warning message should be an Error message

FIN_TRANS_AMOUNTS_CHK message has been changed from Warning to Error because when it is raised it does not allow you to finish the action, so it should be an error instead of a warning.

Fri, 08 May 2015 12:32:19 +0200Fixes issue 29817: Invoices with same documentno are grouped in Add Payment
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 08 May 2015 12:32:19 +0200] rev 26607
Fixes issue 29817: Invoices with same documentno are grouped in Add Payment

Query in AddPaymentOrderInvoicesTransformer has been changed in order to take into account id and documenttype in the group by clause.
DocumentNo was taking into account but not id nor documenttype. Then, when there were two orders/invoices with the same documentno but different documenttypes, they were grouped in the Order/Invoice grid in Add Payment process.
Id group by has been added also to avoid grouping orders/invoices with the same documentno and documenttype.

Thu, 07 May 2015 11:03:35 +0200Fixes issue 29767: "Display logic for grid column" not working
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 07 May 2015 11:03:35 +0200] rev 26606
Fixes issue 29767: "Display logic for grid column" not working

GL Items grid in Add Payment process is not showing accounting dimensions correctly.
The problem was that "Organization" and "Business Partner" fields didn't have display logic defined as "Cost Center", "Project", "1st Dimension" and "2nd Dimension" had, for "Purchase Order", "Sales Order", "Purchase Invoice", "Sales Invoice", "Payment In" and "Payment Out windows", because they were mandatory.
@ACCT_DIMENSION_DISPLAY@ display logic has been added to those fields for those windows.
Now, when executing computeAccountingDimensionDisplayLogic in DimensionDisplayUtility, "Organization" and "Business Partner" fields will be included. Then, contextInfo variable in evaluateDisplayLogicForGridColumns function in ob-pick-and-execute-grid.js will have the proper values for Business Partner and Organization.

Fri, 08 May 2015 14:02:09 +0200Fixed bug 29823: Open/Close Period Control shows calendars associated to organizations
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 08 May 2015 14:02:09 +0200] rev 26605
Fixed bug 29823: Open/Close Period Control shows calendars associated to organizations

The Open/Close Period Control window was showing all the periods available at the C_Period table.
The target of this window is to open/close periods in fiscal calendars, so it should only show periods belonging to a fiscal calendar linked to an organization set as ready.

The fix has 2 parts:
1. Added a hql where clause to include only periods belonging to a fiscal calendar linked to an organization set as ready.
2. The hql filter clause was wrong because it was filtering by the c_period.ad_org_id. Instead it should be filtering by the organization linked to the calendar's periods

Thu, 07 May 2015 12:11:39 +0200Fixed bug 28787: Impossible to create several calendars for the same organization
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Thu, 07 May 2015 12:11:39 +0200] rev 26604
Fixed bug 28787: Impossible to create several calendars for the same organization

Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the Fiscal Calendar | Year tab. It also verifies the periods don't overlap other periods.

The fix consists in checking that there is no date overlap per calendar. Before this fix the calendar wasn't taken into account, so it was not possible to define several calendars for the same organization with the same periods.

Thu, 07 May 2015 16:36:25 +0200Fixes issue 29481: Bad performance when inserting a new Conversion Rate
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 07 May 2015 16:36:25 +0200] rev 26603
Fixes issue 29481: Bad performance when inserting a new Conversion Rate

C_CONVERSION_RATE_TRG2.xml trigger has been deleted. Instead, an event handler has been added in order to check for duplicated conversions only for the currencies you are inserting/updating.
C_CONVERSION_RATE_TRG2.xml trigger was not updated because it produced mutating table error in oracle

Mon, 11 May 2015 13:11:25 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Mon, 11 May 2015 13:11:25 +0200] rev 26602
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Do not start import thread until notified. Make sure that import threads are all deamon threads and that shutdown
works more aggressively.

Fri, 08 May 2015 09:51:11 +0200Fixes bug 29822: Avoid creating unnecessary backdated adjustments.
Unai Martirena <unai.martirena@openbravo.com> [Fri, 08 May 2015 09:51:11 +0200] rev 26601
Fixes bug 29822: Avoid creating unnecessary backdated adjustments.

The problem was happening when costing precision was different from standard precision. When calculating the expected cost of a transaction to know if an adjustment is necessary to be created, it has to be rounded to standard precision because the amounts always have to be created in standard precision. In this case, while comparing expected cost with actual cost from database, as in database values are rounded to standard precision, and expected cost was being rounded to cost precission, an adjustment was being created with the difference, that corresponds just to the precision lost, and finally an adjustment of Zero amount was being created.

Mon, 11 May 2015 11:07:58 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Mon, 11 May 2015 11:07:58 +0200] rev 26600
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Set VariablesSecureApp also when OBContext gets re-used

Mon, 11 May 2015 10:53:02 +0200Fixes bug 29835: Prevents unlimited datasource requests when filtering the grid
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 11 May 2015 10:53:02 +0200] rev 26599
Fixes bug 29835: Prevents unlimited datasource requests when filtering the grid

The problem was that the logic to check that if a datasource request was triggered by scrolling up in a grid that did not have its initial rows loaded (see [1]) did not work well when the user filtered the grid after having scrolled down the grid till loading its second page. This caused the totalRows property of the grid to be miscalculated, and this triggered the undefinite amount of datasource requests.

The logic to check if the request was triggered by scrolling up has been changed. Now, instead of checking low-level smartclient properties like lastScrollTop, we check if there are rows loaded in the positions just after the page that was just received. Only in that case we want to prevent resetting the totalRows property of the ResultSet with the value returned by the datasource.

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

Sun, 10 May 2015 22:16:50 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Sun, 10 May 2015 22:16:50 +0200] rev 26598
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
When processing import entries create a VariablesSecureApp with a 'fake' Request and Session object to better
support in process setting of session and other vars

Sun, 10 May 2015 00:07:35 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Sun, 10 May 2015 00:07:35 +0200] rev 26597
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Set session in variables secure app for default operation, make sure that import entry manager archive
does not start too early

Fri, 08 May 2015 23:52:18 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Fri, 08 May 2015 23:52:18 +0200] rev 26596
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Revert small change to M_OFFER_TYPE table which should not have been committed/pushed

Fri, 08 May 2015 22:36:28 +0200Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Fri, 08 May 2015 22:36:28 +0200] rev 26595
Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Generic part of import entries, table definition, window/tabs, main import entry framework classes

Fri, 08 May 2015 13:37:51 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Fri, 08 May 2015 13:37:51 +0000] rev 26594
CI: merge back from main

Fri, 08 May 2015 13:22:08 +0000CI: update AD_MODULE to version 26577
RM packaging bot <staff.rm@openbravo.com> [Fri, 08 May 2015 13:22:08 +0000] rev 26593
CI: update AD_MODULE to version 26577

Fri, 08 May 2015 11:11:43 +0200Related to bug 28908: Code Review
Unai Martirena <unai.martirena@openbravo.com> [Fri, 08 May 2015 11:11:43 +0200] rev 26592
Related to bug 28908: Code Review

[1]: Only check if any other product is using the image, if current product has an image.
[2]: Make method 'checkImageUtilization' more understandable returning a boolean value instead of a Product object that is not used later on.

Fri, 08 May 2015 09:07:19 +0200Fixed issue 29751: Kill Process
Guillermo Gil <guillermo.gil@openbravo.com> [Fri, 08 May 2015 09:07:19 +0200] rev 26591
Fixed issue 29751: Kill Process

Merge with kill process branch

Fri, 08 May 2015 07:34:27 +0200[Process Kill] Changes after merge, missing ISKILLABLE
Guillermo Gil <guillermo.gil@openbravo.com> [Fri, 08 May 2015 07:34:27 +0200] rev 26590
[Process Kill] Changes after merge, missing ISKILLABLE

Thu, 07 May 2015 15:49:12 +0200[Process Kill] Changes after merge, exported database
Guillermo Gil <guillermo.gil@openbravo.com> [Thu, 07 May 2015 15:49:12 +0200] rev 26589
[Process Kill] Changes after merge, exported database

Thu, 07 May 2015 14:05:54 +0200[Process Kill] Merge with PI
Guillermo Gil <guillermo.gil@openbravo.com> [Thu, 07 May 2015 14:05:54 +0200] rev 26588
[Process Kill] Merge with PI

Fri, 25 Jul 2014 10:08:05 +0200[Process Kill] Code Review
Rafa de Miguel <rafael.demiguel@openbravo.com> [Fri, 25 Jul 2014 10:08:05 +0200] rev 26587
[Process Kill] Code Review

Tue, 22 Jul 2014 10:41:31 +0200[Process Kill] Changes after Merge 2
Rafa de Miguel <rafael.demiguel@openbravo.com> [Tue, 22 Jul 2014 10:41:31 +0200] rev 26586
[Process Kill] Changes after Merge 2