Mon, 05 Jan 2015 16:27:55 +0100Fixed issue 26776: Re-added KS capabilities to filters
David Baz Fayos <david.baz@openbravo.com> [Mon, 05 Jan 2015 16:27:55 +0100] rev 25722
Fixed issue 26776: Re-added KS capabilities to filters
More info at http://wiki.openbravo.com/wiki/Projects:FK_Filter_Keyboard_Shortcuts

Mon, 05 Jan 2015 16:26:06 +0100Related with issue 28469: Updates copyright year in license text
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 05 Jan 2015 16:26:06 +0100] rev 25721
Related with issue 28469: Updates copyright year in license text

Mon, 05 Jan 2015 13:38:32 +0100Fixes issue 28469: Masked string validation is properly done in editable grid
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 05 Jan 2015 13:38:32 +0100] rev 25720
Fixes issue 28469: Masked string validation is properly done in editable grid

There were several problems that were preventing the handling of masked string validations from working properly:
1- The masked string validations were not being performed in grid view, due to this code in the validate function:

if (this.form && this.form.grid && this.form.grid._showingEditor) {
return;
}

That code was put there to prevent doing unneeded validations when a new record was created in the grid view (see issue https://issues.openbravo.com/view.php?id=19176). This issue remains fixed after re
moving these lines.

2- After fixing 1), the Save toolbar button was enabled in the grid view even if the row being edited had masked string validation errores. These happened because of a flaw in the logic to disable the butt
on:

this.setDisabled(... && !hasErrors && ...);

The button was being disabled when the editable form did not have errors, and enabled when the form had errors. Before fixing 1) this did not matter, as hasErrors was always false because the form item
was not being validated. This has been fixed by disabling the button when the form had validation errors.

3- Sometimes (i.e. when the validation was performed due to an autosave) the mask validation was not taken into account. This happened because the validation was added to the validation list of the test it
em, but not to the validation list of the grid field, that is where it was being taken from.

Mon, 29 Dec 2014 18:34:58 +0100Fixes issue 24577: Direct link works properly in grids with implicit filters
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 29 Dec 2014 18:34:58 +0100] rev 25719
Fixes issue 24577: Direct link works properly in grids with implicit filters

When a view was open by pasting a URL link (either in the address bar or in the quick view), the implicit filter of the header grid was always applied, even if the filters had been clea
red before obtaining the link.

This has been fixed by storing in the URL info about the grid filter clause state when the link is obtained. Then, when opening a view from that link, if there were no filter clauses wh
en the link was obtained, the grid will be initialized without them.

Mon, 29 Dec 2014 12:22:58 +0100Fixes bug 28396:Focus not placed in field group if form has no editable fields
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 29 Dec 2014 12:22:58 +0100] rev 25718
Fixes bug 28396:Focus not placed in field group if form has no editable fields

The issue 28396 [1] describes a problem that happens when the first focused field is a field group. This other issue [2] describes a very similar problem, the only difference beinge that instead of being reproduced in general field groups, it was reproduced for the specific audit field group. Its fixes [3], [4] only solved the problem for that particular field group.

The present changeset fixes the problem in a more general way. Instead on checking the type of the field being focused (that will change depending of whether the field group is general or specific (audit, notes, attachments, etc) it calls isc.isA.SectionItem to see whether the focused field is a field group.

[1] https://issues.openbravo.com/view.php?id=28396
[2] https://issues.openbravo.com/view.php?id=28231
[3] https://code.openbravo.com/erp/devel/pi/rev/a72704b89964c9dd369c422ccefeecca16e26551
[4] https://code.openbravo.com/erp/devel/pi/rev/c523abe0e8115d406c7e2515be7aef9d5209ce73

Wed, 31 Dec 2014 19:14:19 +0530Fixes Issue 28197:RM Insert Orphan Line provides a field to provide attribute
Atul Gaware <atul.gaware@openbravo.com> [Wed, 31 Dec 2014 19:14:19 +0530] rev 25717
Fixes Issue 28197:RM Insert Orphan Line provides a field to provide attribute
set instance details for product if applicable.

New parameter is optional and process does not change if parameter is passed
in or not so API checks failure is false positive.

Mon, 29 Dec 2014 18:40:27 +0100Fixes bug 28499:Proper params are used when opening a link using the quick view
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 29 Dec 2014 18:40:27 +0100] rev 25716
Fixes bug 28499:Proper params are used when opening a link using the quick view

The problem was that the OB.Utilities.openDirecTab function, which is used to open a view using the Quick View and also when an URL is pasted in the address bar, tries to fetch the parameters from the current address bar URL. If the link has been entered in the Quick View the parameters won't be available in the address bar, whereas if the view is opened by entering the URL in the address window the view will be opened properly.

This has been fixed by adding the urlParams as an optional parameter to the openDirectTab function. If the parameter is not passed to the function then it will work as usual and it will take its values from the address bar. When the function is called from the quick view the proper parameters are passed, so in this case the url params are not taken from the address bar.

Tue, 30 Dec 2014 10:50:25 +0100Related with issue 28414: Change the error that appears in the log.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Tue, 30 Dec 2014 10:50:25 +0100] rev 25715
Related with issue 28414: Change the error that appears in the log.

An error appears in the log when accessing a window which has a button with not a process nor a process definition assigned to it.

The problem was that the fact of a button with not process nor process definition assigned to it was not taken into account and that was why an url and a command
where not defined.

For fixing this a condition has been added to the function "getURL" and other one to the function "getCommand".
Now if a url or a command is null, a dummy value is given to them. Now, as they have a value, that value can be transformed into a string and the NPE error disappears.

This handles the case when the button is already wrongly configured. In the next step we will avoid making this configuration mistakes in new buttons.

Wed, 24 Dec 2014 16:42:09 +0100Fixed issue 28466: Autosave was executed when creating a new record.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Wed, 24 Dec 2014 16:42:09 +0100] rev 25714
Fixed issue 28466: Autosave was executed when creating a new record.

When a window only has one subtab, and that subtab has a display logic, just after clicking the proper button to create a new
record in the header tab (both in grid and in form mode), the autosave is executed. This happens only the first time that a record is
created.

The problem was in the "updateSubtabVisibility" function of the "ob-standard-view.js".

The problem was that at first, in the function, there was a logic that was not taking into account the fact that if it was the record selected in the header tab has not been saved yet, its subtabs are empty, and it is not neccesary to refresh them.

Before the fix it tried to refresh the subtabs, which resulted in a call to autosave.

For fixing it a new condition has been added to the "updateSubtabVisibility" function. With this new condition
now, the call to the autosave is avoided in the case of the new record.

A new function called "isEditingNewRecord" has been created too. This function returns true if a new record is being edited in the view.

Mon, 29 Dec 2014 11:13:30 +0100Related with issue 28466: Autosave was executed when creating a new record.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Mon, 29 Dec 2014 11:13:30 +0100] rev 25713
Related with issue 28466: Autosave was executed when creating a new record.

The function "saveEditorReply" of the "ob-view-form.js" class has been changed in order to not
having duplicate code.