Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
| ID | ||||||||||||
| 0017522 | ||||||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
| feature request | [Openbravo ERP] A. Platform | minor | always | 2011-06-06 16:45 | 2022-02-01 08:09 | |||||||
| Reporter | ioritzCia | View Status | public | |||||||||
| Assigned To | Triage Platform Base | |||||||||||
| Priority | normal | Resolution | out of date | Fixed in Version | 3.0MP2 | |||||||
| Status | new | Fix in branch | Fixed in SCM revision | |||||||||
| Projection | none | ETA | none | Target Version | ||||||||
| OS | Linux 32 bit | Database | PostgreSQL | Java version | 1.6.0_22 | |||||||
| OS Version | Ubuntu 10.04 | Database version | 8.4 | Ant version | 1.7.1 | |||||||
| Product Version | pi | SCM revision | ||||||||||
| Review Assigned To | ||||||||||||
| Web browser | ||||||||||||
| Modules | Core | |||||||||||
| Regression level | ||||||||||||
| Regression date | ||||||||||||
| Regression introduced in release | ||||||||||||
| Regression introduced by commit | ||||||||||||
| Triggers an Emergency Pack | No | |||||||||||
| Summary | 0017522: Information changed in lines tab does not get automatically refreshed while in header does. | |||||||||||
| Description | While header information is refreshed automatically when something is changed, other tabs' information is not. For example in sales invoice window if some information of the header is changed without modifying anything in the header (for example with a trigger), the change is refreshed automatically. On the other hand, if some information of the lines is changed without modifying the lines (for example with a trigger again), the change is not refreshed automatically. The problem is the user can be seeing wrong information. | |||||||||||
| Steps To Reproduce | A module can be found in attachments. Install it. This module defines a couple of triggers to check this problem. One of the triggers changes some field of the lines when some field in the header is modified. The other one changes a field in the header when a field in the line is changed. When the first one is triggered the information in the lines is not refreshed. When the second one is triggered the information in the header gets automatically refreshed. There is also a video attached showing this behaviour. - Install the module. - Go to Sales Invoice window. - Create a new invoice with a line. - Change the Invoiced Quantity of the line. You will see how the Document No. in the header changes. - Change the Order Reference of the header. Nothing happens in the lines. - Refresh the lines. See that Net Unit Price field refreshes. | |||||||||||
| Tags | No tags attached. | |||||||||||
| Attached Files |  com.openbravo.test-1.0.0.obx [^] (5,739 bytes) 2011-06-06 16:45 video.zip [^] (2,802,668 bytes) 2011-06-06 16:46 LinesUpdate.PNG [^] (77,545 bytes) 2011-06-07 14:03
| |||||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
Notes |
|
|
(0038056) mtaal (manager) 2011-06-06 16:46 |
Rob, Can you give your opinion on this? gr. Martin |
|
(0038091) rgoris (developer) 2011-06-07 10:30 |
After having viewed the video, let me summarize the issue: -Changes in lines push an update into the header. -Changes in the header do not (always?) push an update into the lines. In your case, your module provokes these changes articifically. So what you want to do is to let a change in the header push a change in the lines. Now at this point I cannot think of any other example where a change in the header would provoke a change in the lines unless it is invoked by a process. Can you give an example of a standard window where this is the case? |
|
(0038098) ioritzCia (developer) 2011-06-07 11:11 |
This is an example, the issue is that when some field in the lines gets updated outside the tab of lines, the database changes but the lines do not refresh. As I have said before this is an example and as it happens in lines tabs I suppose it can happen in other tabs. But I also understand that refreshing everything could cause performance problems. Following these steps you can reproduce this behaviour without any custom development. - Create a Sales Order. - Complete/Book it. - Create a Goods Shipment copying lines from the Sales Order. - Without Completing/Booking the Sales Order the delivered quantity of the lines of the Sales Order is 0. - Complete/Book the Goods Shipment. - Now the Delivered Quantity in Sales Order lines is different but it shows 0. - Refresh the Sales Order lines and see that it changes. |
|
(0038099) ioritzCia (developer) 2011-06-07 11:25 |
Due date 08/07/2011 |
|
(0038100) egoitz (developer) 2011-06-07 11:54 |
What is explained on the steps to reproduce is similar what happens when completing a document. In this case, the subtab is also automatically refreshed. Could the refresh of the subtab be forced on a callout? |
|
(0038108) rgoris (developer) 2011-06-07 12:31 |
Thanks for the deeper explanation. The issue is clear now. The behavior you describe is desired but likely will have an impact on performance. I will reassign it to Martin to look into it from a platform POV. |
|
(0038116) mtaal (manager) 2011-06-07 12:39 |
1) If the requirement is to automatically refresh tabs if somehow its information changes somewhere outside of the system --> this is not possible 2) If the requirement is to update the lines if the header changes that is probably possible So only the second can be done, can you let me know if that's okay? gr. Martin |
|
(0038119) rgoris (developer) 2011-06-07 13:31 |
Martin, does your (1) also means that processes outside a "thread" (main tab and all its children) cannot push updates in other threads? In the example above a Goods Shipment is completed which then should force the Sales Order lines to update. I believe that it is possible, because: I tried another scenario where I create a draft sales order, pick a business partner in the header and do not save yet. Now I open another tab with that business partner and change its name. Going back to the unsaved sales order header, i see that the name was updated! This is good. I believe that this should also be possible on lines level, same mechanism. This is also what ioritzCia means. |
|
(0038120) mtaal (manager) 2011-06-07 13:44 |
We recompute values of combos of an opened form when returning to a form, that's it. What is proposed here is to refresh all grids (on all open levels) when a main tab gets selected again. I think that will result in a lesser user experience as a lot of flickering takes place. Note that the issue is bigger, someone else can also change the data and then you will never know until you refresh. This is just the way disconnected web interfaces currently work. In the future we can develop something like broadcasting of changes to clients to refresh their user interface. This is something like 5 days work or so I think. gr. Martin Btw, it is |
|
(0038121) rgoris (developer) 2011-06-07 13:52 |
Clear. I don´t think it is worth the tradeoff (performance and flickering) doing a refresh for all subtabs on return to a tab. The (2) requirement seems doable according to Martin but then we need to make sure there is a user need. All examples above refer to changes caused by other threads (other main tabs) such as Goods Shipment causing change in Sales Order. If we can have a solid case for where lines need to be updated because of a change in their header, please let us know ioritzCia. |
|
(0038122) rgoris (developer) 2011-06-07 14:04 |
I have uploaded an image of a situation where an automatic refresh of a child tab is necessary. Business Partner name has changed in the header and is saved. The child tab is not updated. |
|
(0038123) iciordia (manager) 2011-06-07 14:06 edited on: 2011-06-07 14:07 |
All, we can not refresh everything everytime a change happen or we will kill the performance. In fact I wanted to report a fr to avoid header refresh when changing lines if that's not needed (most of the cases). As a lateral topic, Martin, can you please confirm that we have a pesimistic locking mechanism so if two sessions modify the same record the last one gets an error with an explanation that "someone modified the record in the meantime, please refresh and do your changes again". This is my proposal: -By default there should not be any automatic refresh, so we get best performance. -AD tables can declare what other tables are updated behind the scenes (through triggers or other mechanisms) when that table is updated (new tab in the table & column window). Modules should be able to extend those relationships. -When a tab saves data, it fires a refresh in any other tabs in that session that are linked to tables as per the above relationship. Martin, is that feasible? Can you plese estimate the effort? It seems to me a great fr for someone in the support team to dig into platform details (guided by Martin/Asier). In my opinion this approach gives us full flexibility to describe the system in a proper way without killing the performance. Ismael |
|
(0039105) jonalegriaesarte (reporter) 2011-07-15 17:44 |
news on this topic? |
|
(0039139) mtaal (manager) 2011-07-18 09:51 |
A late reaction, sorry for that. To confirm, yes pessimistic locking is supported as you say Ismael. Ismael, yes your proposal is for sure feasible. I guess it is like 3-4 days work for a medium experienced developer. For the further future (when there is push support) we can support a subscribe-event mechanism, when a window is opened it subscribes for changes to its entities and gets notified when it needs to reload. What would be the next step to get this done, should I assign the issue to someone? gr. Martin |
|
(0051319) azabaleta (developer) 2012-08-16 11:53 |
Why not let the developer of a callout or a event handler (trigger) decide whether to call or not a method to refresh child tabs ? Openbravo 3 core should have a method that a developer could call to solve this. There is only need to have a method to be called for anyone who wants... Please clarify the status of this issue. Thanks. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-06-06 16:45 | ioritzCia | New Issue | |
| 2011-06-06 16:45 | ioritzCia | Assigned To | => mtaal |
| 2011-06-06 16:45 | ioritzCia | File Added: com.openbravo.test-1.0.0.obx | |
| 2011-06-06 16:45 | ioritzCia | Modules | => Core |
| 2011-06-06 16:46 | ioritzCia | File Added: video.zip | |
| 2011-06-06 16:46 | mtaal | Note Added: 0038056 | |
| 2011-06-06 16:46 | mtaal | Status | new => feedback |
| 2011-06-06 16:46 | mtaal | Assigned To | mtaal => rgoris |
| 2011-06-06 16:48 | ioritzCia | Fixed in Version | => 3.0MP2 |
| 2011-06-07 10:30 | rgoris | Note Added: 0038091 | |
| 2011-06-07 11:11 | ioritzCia | Note Added: 0038098 | |
| 2011-06-07 11:20 | egoitz | Issue Monitored: networkb | |
| 2011-06-07 11:25 | ioritzCia | Note Added: 0038099 | |
| 2011-06-07 11:54 | egoitz | Note Added: 0038100 | |
| 2011-06-07 12:31 | rgoris | Note Added: 0038108 | |
| 2011-06-07 12:32 | rgoris | Assigned To | rgoris => mtaal |
| 2011-06-07 12:39 | mtaal | Note Added: 0038116 | |
| 2011-06-07 13:31 | rgoris | Note Added: 0038119 | |
| 2011-06-07 13:44 | mtaal | Note Added: 0038120 | |
| 2011-06-07 13:52 | rgoris | Note Added: 0038121 | |
| 2011-06-07 14:03 | rgoris | File Added: LinesUpdate.PNG | |
| 2011-06-07 14:04 | rgoris | Note Added: 0038122 | |
| 2011-06-07 14:06 | iciordia | Note Added: 0038123 | |
| 2011-06-07 14:07 | iciordia | Note Edited: 0038123 | View Revisions |
| 2011-07-15 17:44 | jonalegriaesarte | Note Added: 0039105 | |
| 2011-07-15 17:44 | jonalegriaesarte | Severity | major => minor |
| 2011-07-18 09:51 | mtaal | Note Added: 0039139 | |
| 2011-08-24 10:36 | ioritzCia | Type | defect => feature request |
| 2012-08-16 11:53 | azabaleta | Note Added: 0051319 | |
| 2013-01-25 14:08 | alostale | Relationship added | related to 0022645 |
| 2016-10-21 10:59 | mtaal | Status | feedback => closed |
| 2016-10-21 10:59 | mtaal | Resolution | open => out of date |
| 2016-10-21 13:17 | mtaal | Tag Attached: MT_closed_out_of_date | |
| 2016-10-21 14:08 | mtaal | Assigned To | mtaal => platform |
| 2016-10-21 14:09 | mtaal | Status | closed => new |
| 2016-10-21 14:11 | mtaal | Tag Detached: MT_closed_out_of_date | |
| 2022-02-01 08:09 | alostale | Assigned To | platform => Triage Platform Base |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |