Fri, 22 Sep 2017 09:55:57 +0200Fixes issue 36877: New Organization selector for Purchase Order Report
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 22 Sep 2017 09:55:57 +0200] rev 32798
Fixes issue 36877: New Organization selector for Purchase Order Report

Fri, 22 Sep 2017 15:22:49 +0200related to issue 36929: revert change due to failure in CI
Carlos Aristu <carlos.aristu@openbravo.com> [Fri, 22 Sep 2017 15:22:49 +0200] rev 32797
related to issue 36929: revert change due to failure in CI

Fri, 22 Sep 2017 14:14:49 +0200fixes bug 36929: include SelectorPickListFieldsDataSourceTest in the test suite
Carlos Aristu <carlos.aristu@openbravo.com> [Fri, 22 Sep 2017 14:14:49 +0200] rev 32796
fixes bug 36929: include SelectorPickListFieldsDataSourceTest in the test suite

Fri, 22 Sep 2017 14:02:09 +0200related to issue 36151, 36863: added test case
Carlos Aristu <carlos.aristu@openbravo.com> [Fri, 22 Sep 2017 14:02:09 +0200] rev 32795
related to issue 36151, 36863: added test case

Fri, 22 Sep 2017 13:24:11 +0200Fixes bug 36908:Updating the column length on table referenced by a view works
Augusto Mauch <augusto.mauch@openbravo.com> [Fri, 22 Sep 2017 13:24:11 +0200] rev 32794
Fixes bug 36908:Updating the column length on table referenced by a view works

There was a problem when a the column length of a table (T) referenced by a view (V) was updated, if that view was referenced by another view (V2).

In the step to update the model, the following steps were done in single batch:
- The views are dropped (forced = true)
- The model is updated (forced = false)
- The views are recreated

What happened is that the view V1 could not be dropped because V2 referenced it (and drop on cascade was not used). Then the batch failed, and only those
commands with forced=true were recreated, so the model was not updated.

To fix this, now the views are dropped in a different batch than the one used to update the model. There is an API change, since before this change this step
was enough to do the whole update of the model:

getSqlBuilder().alterDatabase(currentModel, desiredModel, params);

And now this it is required to call and evalue the following command:

getSqlBuilder().prepareDatabaseForAlter(currentModel, desiredModel, params, changes);

This has been changed in all Openbravo occurrences, and no occurrences outside Openbravo have been found.

Fri, 22 Sep 2017 13:14:08 +0200Related with issue 36112: Minor code review improvements
Inigo Sanchez <inigo.sanchez@openbravo.com> [Fri, 22 Sep 2017 13:14:08 +0200] rev 32793
Related with issue 36112: Minor code review improvements

- Some typos are fixed.
- Improved the name of a method.
- Use getLog().error instead of System.out.
- Now invokeAdDbModified method only execute ad_db_modify('N'). Updated its name to isAdDbModified. Reverted changes in updatedCRC method.

Fri, 22 Sep 2017 11:56:54 +0200fixed bug 36909: encryption/decryption utils were not thread safe
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 22 Sep 2017 11:56:54 +0200] rev 32792
fixed bug 36909: encryption/decryption utils were not thread safe

They could fail when used concurrently because they were sharing an static instance
of a no-thread-safe javax.crypto.Cipher.

Fixed by creating a new Cipher instance whenver it's required to be used.

Fri, 22 Sep 2017 11:53:37 +0200related to bug 36909: added test cases
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 22 Sep 2017 11:53:37 +0200] rev 32791
related to bug 36909: added test cases

which prove that using CryptoUtility methods concurrently fail

Fri, 22 Sep 2017 11:28:57 +0200Fixed issue 36611: Selection is lost when an error is raised removing a record
Inigo Sanchez <inigo.sanchez@openbravo.com> [Fri, 22 Sep 2017 11:28:57 +0200] rev 32790
Fixed issue 36611: Selection is lost when an error is raised removing a record

Backout changeset a6d788e3208b because some problems appears in the common case (succesful deletion). It is decided to fix the most uncommon case (failed deletion) by recovering the selection when the deletion fails.

As mentioned in the original fix, when were removing a row and an error was raising (e.g. Deleting a already processed "Good Shipment" is stopped by a trigger) the selection of the record was lost. This generates an inconsistent grid state that creates all
the reported problems.

Now the problem is fixed by take into account the described situation recovering the selection when the deletion fails. Now the selection is maintained if the record can't be removed properly.

Fri, 22 Sep 2017 10:40:47 +0200Fixes issue 36725: Records cannot be created using grid's contextual menu
Augusto Mauch <augusto.mauch@openbravo.com> [Fri, 22 Sep 2017 10:40:47 +0200] rev 32789
Fixes issue 36725: Records cannot be created using grid's contextual menu

Now if the user cannot add records because its role does not have access to the organization selected in the parent tab, it will not be possible
to add records using the grid's contextual menu.

This needs to be addressed in two different contextuals menus:
- The one shown when right-clicking on a grid record
- The one shown when right-clicking on the grid empty space

Also, simplifies an if condition to check for null/undefined