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