I am very happy to see all the progress that has been done on the platform side. One update I’m not sure that i’m happy with is this new feature:
• Adjusted ChildEntityManager to open child entities in a new tab
I Foresee problems on this side for a lot of apps we have now:
How we use the ChildEntityManager a lot now is in a ‘project’ entity. It was a bit of a nuisance that when going into the ChildEntity the message pops up that you have to save the parametrization of the parent (when a new child entity was created). The benefit of that is that you know for sure that the parametrization of the project is saved and so: the user always uses the latest version of the parent.
Now: by opening the child in a new tab will result in two things:
the users (possibly) is editing on two places in parallel which rely on eachother (we frequently get “last_saved_params” on the parent: but now it isn’t garanteed that this indeed is the last params.
the parent is blocked for other users if it stays open → multiple users could work on one project.
Did you address these things in your design? Because IMO this is a breaking change for some designs…
At least I would like to have the option (as parameter of the childentitymanager) to decide as developer if a new tab should be opened.
Thank you for pointing this out. I’ve already added this to our internal issue tracker, but will try to see if I can retrieve more information about how this change came about, and to see how we can improve on this.
It seems that this change was put about for cases where a ChildEntityManager is added within an editor that has a few steps. If a user would create an entity, and enter the entity, then upon return they would have to start again from step 1.
That makes sense, but even in that case: there is no guarantee that the last_saved_params of the parent is actually the parametrization that the end-user thinks he is using.
It is implied (for an end-user) that you can work on multiple entities simultaneously. It feels a bit that this messes with the statelessness of VIKTOR, the hard thing is that the end-user doesn’t understand that he has to save the current state first before they are used correctly in a child-entity. Imagine if a structural calculation is performed based on incorrect information from a parent-entity because the user forgot to save it? I don’t like that unreliability, and reliability should outweigh going through a few extra steps for the end-user.
I think the best fix would be: let the developer decide what is desirable in a situation.
I see that this feature has been re-implemented again. That reraises my concerns again about guarantees about params state. Maybe the idea is that because of implementing autosave this can be done, but if I pause autosave I still have no guarantee. Apart from that, I dislike having a lot of tabs open.
IF you really want to implement this please let the devs decide (by a entity parameter) if this is desired or not.
Thank you for revisiting this thread. We have indeed changed the behavior of the ChildEntityManager following the release of the autosave functionality.
The old behavior, where a user who navigated to a child from step/page/tab 4 had to start from the beginning when returning to the parent, is a frequently raised UX issue on tree-type apps. Autosave is what has made it possible to solve this, and it is also what addresses the concern you raised earlier. The behavior is as follows:
with autosave enabled: on click the entity is saved first, then the child opens in a new tab
with autosave paused: a save modal is shown when there are unsaved changes, and the child only opens after ‘Save and exit’ or ‘Exit without saving’. ‘Cancel’ keeps the user on the parent
Note that pausing autosave is per entity, so the child always opens with autosave enabled unless the user pauses it there as well.
Your original point about editing in two places in parallel does apply here: opening in a new tab makes it possible to have the parent and child open next to each other. With autosave enabled the parent is saved as the user works, so a child calling the API reads the parent’s current saved params.
You are right that there is one case where the guarantee does not hold. When autosave is paused and the user chooses ‘Exit without saving’, the parent’s changes remain unsaved. If the child then reads last_saved_params of the parent through the API, it uses the last revision rather than the values the user entered. This only happens after the user has explicitly paused autosave and chosen not to save, and the option to continue without saving also existed when the child opened in the same tab. In practice we see that pausing autosave is the exception rather than the norm, by a wide margin.
Your request to make this configurable is clear. I cannot promise a change at this point, as it touches on how much of the navigation behavior should be app-specific rather than consistent across the platform. I have noted it and will follow how the new behavior lands in the coming time. If that changes the picture, I will come back to this thread.
I agree that losing your position in the parent entity is a real UX problem and that the current behaviour improves that for step-based apps. My concern is that this feels like a solution to the symptom rather than the root cause.
Users were already able to open child entities in a new tab through standard browser behaviour whenever they preferred that workflow.
The underlying issue seems to be that navigation state (step/page/tab context) is not preserved in a way that allows returning to the exact location in the parent entity. Solving that would benefit all app types while keeping navigation aligned with standard browser expectations.
I’m also concerned about the side effects of forcing a multi-tab workflow. Users can lose track of where they are, because navigation becomes tab-based rather than following normal browser expectations where a user opens something, inspects it, and uses the Back button to return.
In addition, keeping parent entities open while navigating through child entities encourages more entities to remain open simultaneously. This may increase the likelihood of lock conflicts or situations where other users cannot edit an entity because it remains open in another tab. Even if the locking mechanism itself is unchanged, the platform is effectively encouraging behaviour that can amplify these collaboration issues.
From my perspective, preserving navigation state would be a more fundamental solution than changing the navigation model itself.