Notes |
|
(0038056)
|
mtaal
|
2011-06-06 16:46
|
|
Rob,
Can you give your opinion on this?
gr. Martin |
|
|
(0038091)
|
rgoris
|
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? |
|
|
|
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. |
|
|
|
|
|
(0038100)
|
egoitz
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
2011-07-15 17:44
|
|
|
|
(0039139)
|
mtaal
|
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 |
|
|
|
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. |
|