Old state is shown in Mx6.10.4 when passing an object.

2
We just upgraded our model from 6.9.1 to 6.10.4. We encounter a strange refresh issue where the modeler behaves differently. When going from one screen to the next we have a microflow that changes some values on the main object that we pass to the next screen. What we noticed is that because of some conditional visibility this object was not show. Doing a refresh on this object before passing it to the next form resolves the problem. This seems a change of behaviour to me. I would expect that since I pass the object to the form showing the object that this refresh is not necesarry because the object is not yet shown in the new form. Anybody seen this kind of behaviour? I will do some more testing because and check if I can reproduce this in a new project. Regards, Ronald And would somebody from Mendix add 6.10.4 to the Modeler version in the forum :) [Ticket 50550] [EDIT] This bug is easy to reproduce. Create an object with an enum, create a microflow that changes the enum (commit without refresh)  and show a form passing this object with a conditional visibility on this enum. The form will show the old state. Got a reply from Mendix As per out technical lead, this might be happening due to some changes done for Mendix 7 that were backported to / already included in 6.10.4 which means a refresh is now needed. So beware when you upgrade to 6.10.4. I can understand the reasoning, but this is in my opionion a breaking change because the behaviour changes (a lot). Indeed the workaround is to refresh the object before you pass it. But in a model like ours this is almost undoable to check all microflows.  
asked
2 answers
0

This bug is easy to reproduce. Create an object with an enum, create a microflow that changes the enum (commit without refresh)  and show a form passing this object with a conditional visibility on this enum. The form will show the old state.

We've justed put some more time into the case as described by Ronald and it turns out this behavior is the same in 6.9.1 and even in 5.21.5.

So my initial assessment: this might be happening due to some changes done for Mendix 7 that were backported to / already included in 6.10.4 which means a refresh is now needed.

Was not correct because I based it on the assumption this behavior did change from 6.9.1 to 6.10.4.

Given the above I do not think this is a bug because:

1) The user has object "someEntity" with id "1" in his browser and sends it to the application server (=microflow).
2) The application server creates a copy of the "someEntity" with id "1" and changes one of the attributes.
3) The application tells the browser to go to page "X" and to show "someEntity" with id "1".
4) The browser checks to see if it already has "someEntity" with id "1" in cache. It has, so it will show that one.
5) Since there was no refresh in client triggered from the application server, the browser is still showing the old version.

Fix: add a refresh in client on the change of the entity.

You could argue we should always force a refresh in client on a show page -> parameter entity.

You could also argue the current implemnetation is preferred as changing it will take away control from the developer and break existing functionality for developers relying on the current implementation (there might be cases where you do not want to refresh the entity in the client, for example when changing attributes that are not shown in the client).

So to summarize:

Behavior as described by Ronald did not change from 6.9.1 to 6.10.4 and was already present in 5.21.5. So we do not consider this a bug, it could be considered a feature request. But there are valid reasons as to why the current implementation would be preferred.

If there is another case that does not fit in my description above (like perhaps the one of Nikel) I would suggest filing a separate ticket for that.

answered
2

I encountered the same issue in a slightly different form. When retrieving an object from a datasource microflow, I need to force a feresh as part of the microflow. This results in the whole object state being described twice in the repsonse to the client, but solves the issue that client does not update otherwise. Seems like a clear bug to me.

answered