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 26676
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 26675
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 26674
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 26673
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 26672
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 26671
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 26670
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 26669
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 26668
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 26667
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.