Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminoralways2012-06-11 16:212012-08-23 13:50
ReporterngarciaView Statuspublic 
Assigned ToAugustoMauch 
PriorityhighResolutionfixedFixed in Version3.0MP15
StatusclosedFix in branchpiFixed in SCM revisiond886ecbd34d6
ProjectionnoneETAnoneTarget Version3.0MP15
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionpiSCM revision 
Review Assigned Todbaz
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0020722: Lines of purchase/sales order/invoice do not appear when creating them by process buttons, if the grid is filtered by BP

DescriptionLines of purchase/sales order/invoice do not appear when creating them by process buttons, if the grid is filtered by BP.

Example: if you filter the Sales Invoice grid by a Business Partner and then create a new record, when creating the lines from an order you get the following message in the lines:

"Select a parent record in order to view its children here"

Anyway, the documents are created correctly.
Steps To ReproduceAs a Group Admin Role:
   Go to the Sales Order screen
   Filter the grid by Business Partner
   Create a Sales Order for a different Business Partner
   Click on the "Copy from Order" button
   Select an order and click OK

Notice that the following message is showed in the Lines tab:
   Select a parent record in order to view its children here.
TagsNo tags attached.
Attached Filesdiff file icon issue20722.diff [^] (9,031 bytes) 2012-07-23 16:52 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
has duplicate defect 00212953.0MP15 closedAugustoMauch After create lines from with the grid filtered, the document lines are not correctly refreshed 
related to defect 0021347 closedAugustoMauch Error: Boolean can not be cast to String in Pick and Execute 
related to defect 0021437 closedAugustoMauch The second/third/... lines of sales order do not appear when creating them by process buttons, if the grid is filtered by BP 

-  Notes
AugustoMauch (developer)
2012-07-20 11:19

When a filter is set, the only visible records will be those filtered, and those created after the filter was set. If the form is reloaded, only those filtered will be visible, the ones created after the filter was set will not be shown.

In the steps to reproduce of this issue, a record with business partner 'A' is created after setting a filter on business partner 'B'. Then, the Copy from Order process is used to add lines to the new record. After this process is executed the grid is refreshed, so only the records that comply with the filter will be shown, making the last one created not visible.
AugustoMauch (developer)
2012-07-20 12:34

In this line [1] the current row is refreshed and at this point [2] the whole view is refreshed. When it is refreshed, the filter is used to retrieve the rows that will be shown, and the recently created row will not be shown if it does not comply with the filter.

[1] [^]

[2] [^]
AugustoMauch (developer)
2012-07-20 12:49

The view needs to be refreshed in order to show the new order lines.

Proposed solution: add a new flag, keepCurrentRow to ob-standard-view.refresh and to ob-view-grid.refresh. This flag should modify the criteria, so that not only the fields that comply with the filter are retrieved, but also the currently selected one.
AugustoMauch (developer)
2012-07-20 12:51

This flag would only be used when refreshing the view from the closeProcessPopup function. When the view is refreshed using the refresh button in the status bar, only the filtered rows should be retrieved.
rgoris (developer)
2012-07-23 10:40

In reply to Augusto┬┤s question below [1]:

RGO: In grid mode it works as intended. When the user inserts a new row, and saves it, it should be visible, even though the column filter would exclude it. A refresh is an deliberate action and will re-apply the filter.

In form mode however, no grid filters should be applied at all. The form mode does not need or want to know about underlying grid filters. So after having saved a new form, no filters are applied. When the form view is closed, filters will be applied to the grid.

For processes (regardless whether they are invoked from grid or form view, and this is the initial issue mentioned by ngarcia) the behavior should be as such that the newly created record is visible until a user-initiated refresh is done. So, it should behave as if a new row was inserted into the grid regularly.

Generic statement: any new or modified record (either by the user or by a process) must be visible after having saved, regardless of filters.

[1] "Hi Rob,

Hi have been talking to Ivan about how the refresh in the grid view should work, and we would like to have your feedback.

This is how it currently works:
1) if the user enters a text in a filter (i.e. 'Hoteles buenas noches' in the business partner field of the header tab of the sales order window), initially only the records that comply with the filter are shown.
2) if the user then adds a new record, but with contents that do not comply with the filter (i.e. a new order with business partner = 'Alimentos y supermercados'), then the visible registers will be those that comply with the filter plus the new one.
3a) if the user then clicks the refresh button, then only the records that comply with the filter will be shown
3b) if the user executes a process (i.e. Copy from order) on the recently created record, the the process is completed there will be an implicit refresh, and the record will not be visible in the grid (see [1]).
I think that 3a) works as intented, but that in 3b) the record that has been used for the process should not dissapear after the process is completed should remain visible. So, the general rule would be:

if the user executes an explicit refresh, only the records that comply with the filter will be shown
after executing a process on a record, that record should remain visible after the implicit refresh is executed.
What do you think? Could you post a note in [1] about how this should work?"
AugustoMauch (developer)
2012-07-23 16:54

The fix for this issue is risky, because it has required to change the code used to filter the grid records.

The fix will be pushed to pi for mp15, and for now it is available attached to this issue.
hgbot (developer)
2012-08-06 08:35

Repository: erp/devel/pi
Changeset: d886ecbd34d679352b46ba22fe368727e5773fe8
Author: Augusto Mauch <augusto.mauch <at>>
Date: Mon Aug 06 08:34:05 2012 +0200
URL: [^]

Fixes issue 20722: Selected record does not dissapear after button processing

When the grid is refreshed due to the execution of a process, the selected record does not dissapear, even if it does not comply with the filter criteria. But, if the user clicks on the Refresh Grid button, the only records that will be shown will be those that match the filter.

M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/grid/ob-grid.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/grid/ob-view-grid.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/toolbar/ob-action-button.js
hgbot (developer)
2012-08-14 13:16

Repository: erp/devel/pi
Changeset: 0ce5bb9039c27899d455693e3e6895e8f9d345e1
Author: Augusto Mauch <augusto.mauch <at>>
Date: Tue Aug 14 13:15:32 2012 +0200
URL: [^]

Fixes issue 21347: Fixed call to old version of refresh()

In the fix os issue 20722, the signature of the refresh function was added to include a third parameter. There were in the code calls to a previous version of that function, that needed to be updated to support the new signature.

M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-window.js
AugustoMauch (developer)
2012-08-14 14:37

Issue reopened to enter Closed by field
dbaz (developer)
2012-08-23 13:50

This issue strictly fixed what is described in it. But the solution is not complete, so new issue 21437 has been opened.

Anyway this issue is fixed, so I close it.

Reviewed @ changeset: 17752 - f1c506df75cd

- Issue History
Date Modified Username Field Change
2012-06-11 16:21 ngarcia New Issue
2012-06-11 16:21 ngarcia Assigned To => mirurita
2012-06-11 16:21 ngarcia Modules => Core
2012-06-11 16:25 mirurita Assigned To mirurita => jonalegriaesarte
2012-06-12 12:55 ngarcia Issue Monitored: networkb
2012-06-21 12:18 ioritzCia Assigned To jonalegriaesarte => alostale
2012-06-21 12:18 ioritzCia Category 03. Procurement management => A. Platform
2012-07-20 11:19 AugustoMauch Note Added: 0050771
2012-07-20 12:34 AugustoMauch Note Added: 0050778
2012-07-20 12:49 AugustoMauch Note Added: 0050779
2012-07-20 12:49 AugustoMauch Assigned To alostale => AugustoMauch
2012-07-20 12:51 AugustoMauch Note Added: 0050780
2012-07-23 10:40 rgoris Note Added: 0050790
2012-07-23 16:52 AugustoMauch File Added: issue20722.diff
2012-07-23 16:54 AugustoMauch Note Added: 0050797
2012-07-23 16:55 AugustoMauch Status new => scheduled
2012-07-23 16:55 AugustoMauch fix_in_branch => pi
2012-07-23 17:03 jonalegriaesarte Target Version 3.0MP14 => 3.0MP15
2012-07-23 17:03 jonalegriaesarte fix_in_branch pi =>
2012-08-06 08:35 hgbot Checkin
2012-08-06 08:35 hgbot Note Added: 0051102
2012-08-06 08:35 hgbot Status scheduled => resolved
2012-08-06 08:35 hgbot Resolution open => fixed
2012-08-06 08:35 hgbot Fixed in SCM revision => [^]
2012-08-06 09:37 AugustoMauch Relationship added has duplicate 0021295
2012-08-14 13:11 AugustoMauch Relationship added related to 0021352
2012-08-14 13:13 AugustoMauch Relationship deleted related to 0021352
2012-08-14 13:13 AugustoMauch Relationship added related to 0021347
2012-08-14 13:16 hgbot Checkin
2012-08-14 13:16 hgbot Note Added: 0051280
2012-08-14 14:37 AugustoMauch Note Added: 0051294
2012-08-14 14:37 AugustoMauch Status resolved => new
2012-08-14 14:37 AugustoMauch Resolution fixed => open
2012-08-14 14:37 AugustoMauch Closed by => dbaz
2012-08-21 21:53 AugustoMauch Status new => scheduled
2012-08-21 21:53 AugustoMauch fix_in_branch => pi
2012-08-21 21:53 AugustoMauch Status scheduled => resolved
2012-08-21 21:53 AugustoMauch Resolution open => fixed
2012-08-23 13:45 dbaz Relationship added related to 0021437
2012-08-23 13:50 dbaz Note Added: 0051503
2012-08-23 13:50 dbaz Status resolved => closed
2012-08-23 13:50 dbaz Fixed in Version => 3.0MP15

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker