Thu, 14 May 2015 17:12:18 +0200Related to bu 29891: Adjust costing tests to the new behavior
Unai Martirena <unai.martirena@openbravo.com> [Thu, 14 May 2015 17:12:18 +0200] rev 26715
Related to bu 29891: Adjust costing tests to the new behavior

Thu, 14 May 2015 17:11:31 +0200Fixes bug 29891: Total Movement qty fixed in costing tab with backdated trx
Unai Martirena <unai.martirena@openbravo.com> [Thu, 14 May 2015 17:11:31 +0200] rev 26714
Fixes bug 29891: Total Movement qty fixed in costing tab with backdated trx

While working with cost adjustments, on certain cases the existing Costing records changes. This can happen because the cost has been recalculated due to backdated transactions, price adjustments, manual cost corrections, etc. In all this cases the 'Total Movement Quantity' field was not being correctly updated.
This field has to store the current stock of the product on that moment. So, each time the costing record is updated it is being checked if this value changes, and if it has changed the current stock is set.

Mon, 11 May 2015 10:53:02 +0200Fixes bug 29838: Prevents unlimited datasource requests when filtering the grid
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 11 May 2015 10:53:02 +0200] rev 26713
Fixes bug 29838: 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

Fri, 08 May 2015 14:02:09 +0200Fixed bug 29827: 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 26712
Fixed bug 29827: 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 29808: 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 26711
Fixed bug 29808: 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.

Mon, 11 May 2015 10:15:38 +0200Fixes bug 29836: Avoid creating unnecessary backdated adjustments.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 11 May 2015 10:15:38 +0200] rev 26710
Fixes bug 29836: 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.

Wed, 06 May 2015 11:09:24 +0200Fixed bug 29780 The done button appears disabled when it should not
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 06 May 2015 11:09:24 +0200] rev 26709
Fixed bug 29780 The done button appears disabled when it should not

null parameter when it should be the view in recalcDisplayLogicOrReadOnlyLogic
call in updateDifference function

Thu, 21 May 2015 09:19:25 +0000Merge temporary head for 3.0PR15Q1.4
RM packaging bot <staff.rm@openbravo.com> [Thu, 21 May 2015 09:19:25 +0000] rev 26708
Merge temporary head for 3.0PR15Q1.4

Tue, 19 May 2015 12:57:06 +0000Added signature for changeset ac3537eef819
RM packaging bot <staff.rm@openbravo.com> [Tue, 19 May 2015 12:57:06 +0000] rev 26707
Added signature for changeset ac3537eef819

Tue, 19 May 2015 12:57:05 +0000Added tag 3.0PR15Q1.4 for changeset d5ec99ff8e8e
RM packaging bot <staff.rm@openbravo.com> [Tue, 19 May 2015 12:57:05 +0000] rev 26706
Added tag 3.0PR15Q1.4 for changeset d5ec99ff8e8e

Tue, 19 May 2015 12:57:05 +0000Update AD_MODULE version to 3.0PR15Q1.4 3.0PR15Q1.4
RM packaging bot <staff.rm@openbravo.com> [Tue, 19 May 2015 12:57:05 +0000] rev 26705
Update AD_MODULE version to 3.0PR15Q1.4

Thu, 07 May 2015 12:11:39 +0200Fixed bug 29809: 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 26704
Fixed bug 29809: 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.

Tue, 19 May 2015 14:04:18 +0200Related to issue 29809: Backout wrong changeset
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Tue, 19 May 2015 14:04:18 +0200] rev 26703
Related to issue 29809: Backout wrong changeset

The changeset pushed was not the good one, and failed in Oracle

Mon, 18 May 2015 17:22:42 +0200Related to bug 29885: Code Review
Unai Martirena <unai.martirena@openbravo.com> [Mon, 18 May 2015 17:22:42 +0200] rev 26702
Related to bug 29885: Code Review

Add coalesce in case there is no batch associated to set GL Journal Org, in order to avoid issues in the if condition done right after the query if null values are compared

Thu, 14 May 2015 16:20:05 +0200Fixes issue 29885: Error while completing a Simple G/L Journal in Oracle
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 14 May 2015 16:20:05 +0200] rev 26701
Fixes issue 29885: Error while completing a Simple G/L Journal in Oracle

A query in gl_journal_post has been changed to avoid errors in Oracle when retrieving a null id

Thu, 14 May 2015 17:23:03 +0200Fixes issue 29890 & Fixes issue 29888: Error in Price Correction Background
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 14 May 2015 17:23:03 +0200] rev 26700
Fixes issue 29890 & Fixes issue 29888: Error in Price Correction Background

IsCostCalculated will not be considered to set CheckPriceDifference flag, when completing an invoice.
Instead, when running Price Correction Background, transactions will be filtered by IsCostCalculated to avoid calculate price differences in transactions where cost has not been calculated.

Fri, 15 May 2015 12:01:31 +0200Fixes issue 29900: False positives in GLJournalAccountingCheck validation
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Fri, 15 May 2015 12:01:31 +0200] rev 26699
Fixes issue 29900: False positives in GLJournalAccountingCheck validation
Missing ad_table_id constraint ends up in wrong validation when there are old records using numeric values for ids.

Tue, 05 May 2015 16:39:53 +0200Fixed issue 29776: Header of warehouse picking module do not refresh
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 05 May 2015 16:39:53 +0200] rev 26698
Fixed issue 29776: Header of warehouse picking module do not refresh

Header of warehouse picking module do not refresh in some circunstances.

Issue of platform.

The problem was that the toolbar didn't update when the Manage Incidences
process finished.

The solution is to update the toolbar when the ActionHandler return the
responded JSON.

Thu, 14 May 2015 17:08:37 +0200Fixes bug 29892: Total Movement qty fixed in costing tab with backdated trx
Unai Martirena <unai.martirena@openbravo.com> [Thu, 14 May 2015 17:08:37 +0200] rev 26697
Fixes bug 29892: Total Movement qty fixed in costing tab with backdated trx

While working with cost adjustments, on certain cases the existing Costing records changes. This can happen because the cost has been recalculated due to backdated transactions, price adjustments, manual cost corrections, etc. In all this cases the 'Total Movement Quantity' field was not being correctly updated.
This field has to store the current stock of the product on that moment. So, each time the costing record is updated it is being checked if this value changes, and if it has changed the current stock is set.

Wed, 13 May 2015 18:06:30 +0200Fixes issue 29873: Wrong accounts when posting multi-general ledger G/L Journal
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 13 May 2015 18:06:30 +0200] rev 26696
Fixes issue 29873: 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

Tue, 17 Mar 2015 11:56:11 +0100Fixes issue 29876: 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 26695
Fixes issue 29876: 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, 11 May 2015 10:53:02 +0200Fixes bug 29839: Prevents unlimited datasource requests when filtering the grid
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 11 May 2015 10:53:02 +0200] rev 26694
Fixes bug 29839: 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

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 26693
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 29809: 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 26692
Fixed bug 29809: 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.

Mon, 11 May 2015 10:16:45 +0200Fixes bug 29837: Avoid creating unnecessary backdated adjustments.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 11 May 2015 10:16:45 +0200] rev 26691
Fixes bug 29837: 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.

Wed, 06 May 2015 18:01:12 +0200related to issue 28971, related to issue 29781
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 06 May 2015 18:01:12 +0200] rev 26690
related to issue 28971, related to issue 29781

handleButtonsStatus function does not exist in q1

Wed, 06 May 2015 17:33:29 +0200related to issue 29781 apply js beautifier
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 06 May 2015 17:33:29 +0200] rev 26689
related to issue 29781 apply js beautifier

Wed, 06 May 2015 11:09:24 +0200Fixed bug 29781 The done button appears disabled when it should not
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 06 May 2015 11:09:24 +0200] rev 26688
Fixed bug 29781 The done button appears disabled when it should not

null parameter when it should be the view in recalcDisplayLogicOrReadOnlyLogic
call in updateDifference function

Mon, 04 May 2015 14:06:00 +0200Fixed bug 29760:Problems with inherited permissions in process definition
Inigo Sanchez <inigo.sanchez@openbravo.com> [Mon, 04 May 2015 14:06:00 +0200] rev 26687
Fixed bug 29760:Problems with inherited permissions in process definition

The problem was that when a process containing parameters defined as "window" is
launched , this manual role has not access to windows contained in that process
definition.

The cause of this issue is that before 14Q3, no security check was done on P&E
grids, so data always was retrieved.From 15Q1, security is checked requiring
explicit access to P&E grid.

The issue is fixed by inheriting access from the process, this is if the process
is accessible the grid within the P&E doesn't require to have explicit access
but inherits from the process itself.

Mon, 04 May 2015 13:29:55 +0200Fixes bug 29761: getCallableResult broken when using null parameters.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 04 May 2015 13:29:55 +0200] rev 26686
Fixes bug 29761: getCallableResult broken when using null parameters.

Removed TEST value for default