Fri, 13 Oct 2017 14:09:41 +0200Related to issue 36966: Update license text
Guillermo Alvarez de Eulate <guillermo.alvarez@openbravo.com> [Fri, 13 Oct 2017 14:09:41 +0200] rev 32865
Related to issue 36966: Update license text

Fri, 13 Oct 2017 12:03:15 +0200fixed bug 28479: unneeded queries to ad_langue
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 13 Oct 2017 12:03:15 +0200] rev 32864
fixed bug 28479: unneeded queries to ad_langue

Backports HHH-11703 [1] Hibernate issue that adds objects initialized by a
unique contraint to 1st level cache. In this way, only one query per different
language is executed per request (which typically is just one) instead one per
record initialized.

Find code for backport here [2].

---
[1] https://hibernate.atlassian.net/browse/HHH-11703
[2] https://github.com/alostale/hibernate-orm

Thu, 12 Oct 2017 10:44:52 +0200Related to issue 36966: Add PL function to retrieve json details about certain m_attsetinstance_id
Guillermo Alvarez de Eulate <guillermo.alvarez@openbravo.com> [Thu, 12 Oct 2017 10:44:52 +0200] rev 32863
Related to issue 36966: Add PL function to retrieve json details about certain m_attsetinstance_id

Wed, 11 Oct 2017 11:12:21 +0200Related to Issue 36693. Code Review Changes:
David Miguelez <david.miguelez@openbravo.com> [Wed, 11 Oct 2017 11:12:21 +0200] rev 32862
Related to Issue 36693. Code Review Changes:

* Improved error message when standard precission is a negative number
* Improved some Java Doc
* Removed some unnecessary Java Doc
* Reordering tags in definition of constants to compile with standards
* Rearranged Code to improve redability
* Added log.error when file has not been found

Fri, 06 Oct 2017 10:25:41 -0400Fixes issue 36693:Std precision can be higher than the currency's real precision
Mark <markmm82@gmail.com> [Fri, 06 Oct 2017 10:25:41 -0400] rev 32861
Fixes issue 36693:Std precision can be higher than the currency's real precision

In Currency window, Standard precision can be higher than the currency's real
precision (commonly 2). The Standard Precision is used to round all the amounts
(not prices) of the documents created in the backend.

Was created a new callout used to validate the currency standard precision. If
the new precision is higher than specified currency precision in ISO 4217 Currency
codes, then a warning is showed to user.

Also, if the new precision is negative then an error message is shown and it is
set as the default standard precision: 2.

Wed, 11 Oct 2017 17:34:31 +0200Fixed issue 37051: Rich text area fields causes visibility problems in the grid
Inigo Sanchez <inigo.sanchez@openbravo.com> [Wed, 11 Oct 2017 17:34:31 +0200] rev 32860
Fixed issue 37051: Rich text area fields causes visibility problems in the grid

The problem was that the rich text area fields generated visibility problems in the grid under some circumstances.
(e.g. when a rich text area field has a carriage return or html tags such as div, br,etc.). A common usecase could
be when a text is copied from a website.

This visibility problems occurred because in form view this type of fields are visualized as a rich text editor and
html tags are supported but in grid view are visualized as a normal field in the grid and this html tags are not
properly handled by SC.

In order to avoid this grid visibility problems, when showing a rich text area field in grid view, now it is escaped
the html code. Visibility in form view is not changed. Now the problem has been fixed by taking account this situation
in getGridFieldProperties method of the RichTextUIDefinition reference.

Tue, 10 Oct 2017 10:04:55 +0200Related to Issue 36878. Code Review Fixes
David Miguelez <david.miguelez@openbravo.com> [Tue, 10 Oct 2017 10:04:55 +0200] rev 32859
Related to Issue 36878. Code Review Fixes

* In ReportValuedStock.java, when looking for the last costing rule
filter by validated costing rules
* In queries, check that the warehouses are equal only when the warehouse
dimension is Y
* Use left join with the M_Costing subqueri instead of a join

Mon, 09 Oct 2017 18:28:14 +0200Related to Issue 36878. Code Review fixes:
David Miguelez <david.miguelez@openbravo.com> [Mon, 09 Oct 2017 18:28:14 +0200] rev 32858
Related to Issue 36878. Code Review fixes:

* Removed query to retrieve last M_Costing in Consolidated with cost query
for the group of Transactions without Cost calculated. This must be null
* Take into account Warehouse Dimension in both queries that look for costs
- In not consolidated, if the Warehouse Dimension is checked, the Warehouse
of the Costing record must be the same one as the Transaction
- In the consolidated, the Organization of the Warehouse of the Costing record
must belong to the Organization of the filter of the Report. In this case,
the average of the Costing records must be returned as the last costing record

Thu, 28 Sep 2017 13:08:49 -0400Fixes issue 36878: [Valued Stock Report]: Wrong Actual Cost and Valuation
Mark <markmm82@gmail.com> [Thu, 28 Sep 2017 13:08:49 -0400] rev 32857
Fixes issue 36878: [Valued Stock Report]: Wrong Actual Cost and Valuation
if the costing rule is validated with warehouse dimension.

Incorrect computation was made because costs related to transactions were not
grouped by warehouse and more than one cost could be showed with the cost of the
current line related to it. To fix this issue were took into account that if the
costing rule has the warehouse dimension activated, costs will be related to them
and calculated taking into account the transaction's warehouse. If the costing rule
hasn't the Warehouse dimension activated, then cost doesn't has the warehouse column
filled. Both cases are taken into account to a correct computation of costs.

Also was fixed when Consolidated warehouse option is choosed.

Mon, 09 Oct 2017 12:39:56 +0200Fixed issue 37005: Error importing C_UOM translation
Inigo Sanchez <inigo.sanchez@openbravo.com> [Mon, 09 Oct 2017 12:39:56 +0200] rev 32856
Fixed issue 37005: Error importing C_UOM translation

The problem was discovered when you was trying to import the es_ES translation for Core. Running install.source
task (having org.openbravo.localization.spain.referencedata.translation.esES module in the instance) some C_UOM
translations were not found. The problem was the order in wich translations were applied. (Before the import of
standard reference data).

The ApplyModule task import the data first for any translation modules. Then ApplyModule task import the reference
data modules. This order is wrong because some translations could be depend on the reference data.

Now the problem has been resolved by take into account this situation. Now, the import of the reference data are
done at first. Then the translations are applied.

Fri, 06 Oct 2017 09:56:55 +0200Fixed issue 36610: 3* flush called to insert/save 1 record in generated windows
Inigo Sanchez <inigo.sanchez@openbravo.com> [Fri, 06 Oct 2017 09:56:55 +0200] rev 32855
Fixed issue 36610: 3* flush called to insert/save 1 record in generated windows

Those flushes were added for pre/post actions, which in most of the cases are unimplemented. For this
reason, removing those two flushes would improve the common case.

After removing those flushes, it is required to move those flushes to pre/post actions implemented in
org.openbravo.module.resources module.

The problem has been resolved because the extra flushes are removed.

Thu, 05 Oct 2017 18:31:11 +0200fixes bug 37016: Disable print/e-mail buttons on record creation in grid view
Carlos Aristu <carlos.aristu@openbravo.com> [Thu, 05 Oct 2017 18:31:11 +0200] rev 32854
fixes bug 37016: Disable print/e-mail buttons on record creation in grid view

Thu, 05 Oct 2017 16:00:35 +0200fixes issue 36916: PG10 - update.database fails if there are DB sequences
Carlos Aristu <carlos.aristu@openbravo.com> [Thu, 05 Oct 2017 16:00:35 +0200] rev 32853
fixes issue 36916: PG10 - update.database fails if there are DB sequences

Mon, 02 Oct 2017 15:17:11 +0200Fixed bug 36928: Emails sent by alerts contains information about other clients
Inigo Sanchez <inigo.sanchez@openbravo.com> [Mon, 02 Oct 2017 15:17:11 +0200] rev 32852
Fixed bug 36928: Emails sent by alerts contains information about other clients

The problem was that emails sent by alerts contains information about other entities. For example, when sending
an alert by email within the 'White Valley Group Admin' client, it also sends information about 'F&B Group Admin'
client. The generation of the body of the email was filtering by organization but was not filtering by client too.

The problem has been resolved by take into account the client info properly. Now the data used in the generation
of the email is filtering properly.

Wed, 04 Oct 2017 11:08:32 +0200Fixed bug 36886:install.source finishes with success even if an error is raised
Inigo Sanchez <inigo.sanchez@openbravo.com> [Wed, 04 Oct 2017 11:08:32 +0200] rev 32851
Fixed bug 36886:install.source finishes with success even if an error is raised

The problem is that install.source task could finished with success even if a view cannot be created. If there is a
problem with the definition of a view (i.e. the view references a table that does not exist), the install.source
task will finish with a success message, even though error logs will be written in console output. If the
update.database task is executed instead of install.source, the task will end with error.

Now the problem has been resolved by take into account the same errors/problems on install.source task than on
update.database. The following methods now are managed in order to retrieve the potential errors and stop the
task if and error is raised:
- platform.createTables(..)
- platform.createAllFKs(..)
- platform.enableAllTriggers(..)

Now on install.source taks the errors are handled properly.

Tue, 03 Oct 2017 17:10:26 +0200fixes bug 36931: Check data access level of process definitions
Carlos Aristu <carlos.aristu@openbravo.com> [Tue, 03 Oct 2017 17:10:26 +0200] rev 32850
fixes bug 36931: Check data access level of process definitions

The data access level of the process definition was not being checked. Now, it is verified in the BaseProcessActionHandler before executing any action. In particular the check will be performed by the defaults action handler of each process definition.

In addition, some code has been added for the OBBaseParameterWindowView class, in order to handle properly in the client the error message coming from the server side when the access level of the process definition is not allowed in the current context

Thu, 28 Sep 2017 13:19:06 +0200fixes bug 36970: Return focus to the record if failed to be edited in grid view
Carlos Aristu <carlos.aristu@openbravo.com> [Thu, 28 Sep 2017 13:19:06 +0200] rev 32849
fixes bug 36970: Return focus to the record if failed to be edited in grid view

When a record failed to be edited in grid view right after moving to the form view of its parent record, the window ended in an inconsitent state:
- The focus was placed at the header
- The active view still was the child tab

This was not happening when editing the child record in form view, because the focus was always returned to the form. To fix the problem now the same behavior has been implemented in grid view: in the described scenario the focus is returned to the edit form of the grid.

Besides, the "editRow" and "editSession" variables were unused in the editFailed() function. Thus, both have been removed.

Thu, 28 Sep 2017 09:47:25 +0200fixes bug 35136: Line seems to be saved with error after saving the header
Carlos Aristu <carlos.aristu@openbravo.com> [Thu, 28 Sep 2017 09:47:25 +0200] rev 32848
fixes bug 35136: Line seems to be saved with error after saving the header

When saving a record, the content of its child tabs is automatically refreshed. In case we leave a child record in error status and then we edit and save its parent record, the content of the child record is automatically refreshed with the server data and the error state in the UI disappears, nevertheless, the problem was that the edits was not being discarded properly causing the record to show outdated information.

Now when the tab is refreshed if it contains records with errors, then the edits are discarded allowing to show the real contents of the records.

Tue, 03 Oct 2017 16:24:09 +0200related to issue 36927: update copyright year
Carlos Aristu <carlos.aristu@openbravo.com> [Tue, 03 Oct 2017 16:24:09 +0200] rev 32847
related to issue 36927: update copyright year

Tue, 26 Sep 2017 12:41:49 +0200fixes bug 36927: Multiple DS requests having a date item as first focused item
Carlos Aristu <carlos.aristu@openbravo.com> [Tue, 26 Sep 2017 12:41:49 +0200] rev 32846
fixes bug 36927: Multiple DS requests having a date item as first focused item

When directly opening a record in a tab which has a date item as the first focused item, extra DS calls were fired which could prevent the record to be opened properly (the form displayed in blank)

This has happening because a combination of different facts:

- When the grid is redrawn, Smarclient fires an update of the first focused item. In the case of date items this causes that false item edition is fired because it detects that the value of the date item filter changes from undefined to empty string.

- If the previous scenario happens while opening a record directly, the grid datasource detects that it needs to fetch data because at this point the number of cached rows is different from the total rows (see [1]).

To avoid those extra DS requests we now ignore those false item editions while a target record is being opened.

[1] https://code.openbravo.com/erp/mods/org.openbravo.userinterface.smartclient.dev/file/66d2b640b66e/web/org.openbravo.userinterface.smartclient/isomorphic/client/application/ResultSet.js#l833

Tue, 03 Oct 2017 13:50:17 +0200fixed issue 36938, fixed issue 36996: dbsm for these issues
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 03 Oct 2017 13:50:17 +0200] rev 32845
fixed issue 36938, fixed issue 36996: dbsm for these issues

- removed unused platforms
- refactorized code to better reuse in tests
- test properly apply ad updates

Mon, 02 Oct 2017 17:19:19 -0400Fixes issue 36969: Purchase order created from Requisitions created with 0 price
Mark <markmm82@gmail.com> [Mon, 02 Oct 2017 17:19:19 -0400] rev 32844
Fixes issue 36969: Purchase order created from Requisitions created with 0 price

Purchase order lines created from Requisitions are created with 0 price if price
list includes taxes and a discount is defined.

When M_REQUISITION_CREATEPO process is executed it creates the order and its lines.
Then it call the C_ORDER_POST1, to process the created order and it calls the
M_PROMOTION_CALCULATE to recalculate prices and quantities if discounts, and in
this case it uses the grosspricestd of lines to recalculates the gross_unit_price
and line_gross_amount if price list includes taxes:

if (v_taxIncluded = 'Y') then
update c_orderline set
gross_unit_price = grosspricestd,
line_gross_amount = round(grosspricestd * qtyordered, v_stdPrecision)
where c_orderline_id = Cur_Order.id;

The process was failling because order lines were created without a GROSSPRICESTD
column defined, and it was taking 0 instead of the right price. Due that, when the
values of the lines were recalculated to apply discounts it reset all values to ZERO
and order ends with incorrect totals.

To avoid that, the GROSSPRICESTD is defined when the lines are created.

Sun, 01 Oct 2017 19:56:56 -0400Fixes issue 36889: Wrong stock shown if Generate Aggregated Data Background
Mark <markmm82@gmail.com> [Sun, 01 Oct 2017 19:56:56 -0400] rev 32843
Fixes issue 36889: Wrong stock shown if Generate Aggregated Data Background
process is launched with two costing rules for same organization

Wrong stock shown if Generate Aggregated Data Background process is launched with
two costing rules for same organization.

Problem was that conditions in getCostingRules() method had conditions that retrieved
more than one costing rule for the same period because an incorrect condition when
validated if starting and ending dates are null.

To fix the problem was restructured the query to combine the three conditions in just two
conditions that includes the third one (period is completely included inside the costing
rule range) and avoid return more than one costing rule for period is processed.

Also, was replaced cr.organization.id in (:org) for cr.organization.id = :org) as :org
parameter will be only one organization and not a list of organizations.

Tue, 03 Oct 2017 07:57:51 +0200fixed bug 36984: 2.50->pi upgrade fails
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 03 Oct 2017 07:57:51 +0200] rev 32842
fixed bug 36984: 2.50->pi upgrade fails

Fixed jar which was generated from an incorrect version

Tue, 03 Oct 2017 07:52:31 +0200fixed bug 36984: 2.50->pi upgrade fails
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 03 Oct 2017 07:52:31 +0200] rev 32841
fixed bug 36984: 2.50->pi upgrade fails

If failed becuse of the order source data rows are inserted/deleted/updated.

Before 35653 was fixed, rows were sorted by their ID and insertions deltions
and updates were performed in that order. Afterwars, rows were sorted in the
same way, but insertions and deletions were performed before updates.

This casues that, in some weird cases, constraints to be broken while updating
making the process to fail.

Now it has been fixed by restoring previous order, so that updates are not
postponed anymore.

Mon, 02 Oct 2017 15:43:05 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 02 Oct 2017 15:43:05 +0000] rev 32840
CI: merge back from main

Mon, 02 Oct 2017 15:29:13 +0000CI: update AD_MODULE to version 32838
RM packaging bot <staff.rm@openbravo.com> [Mon, 02 Oct 2017 15:29:13 +0000] rev 32839
CI: update AD_MODULE to version 32838

Mon, 02 Oct 2017 12:02:08 +0200Related to issue 36723: Changes in M_Locator inventory status for QA client
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 02 Oct 2017 12:02:08 +0200] rev 32838
Related to issue 36723: Changes in M_Locator inventory status for QA client

Tue, 30 Aug 2016 21:43:29 +0200Fixes issue 33808: Fix to unprocessed transactions are shown in Match statement
Sanjota <sanjota.nelagi@promantia.com> [Tue, 30 Aug 2016 21:43:29 +0200] rev 32837
Fixes issue 33808: Fix to unprocessed transactions are shown in Match statement

Made changes to not show not processed transactions in the Match Statement window
Put transaction's processed field as filter while fetching transaction records.

Fri, 29 Sep 2017 10:50:49 +0200Fixes issue 36973: Random failure in testCostingV11
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 29 Sep 2017 10:50:49 +0200] rev 32836
Fixes issue 36973: Random failure in testCostingV11