Semantic model tree closes completely after each change to a variable after saving

[vodair]

The problem

The semantic model tree closes completely after every change after saving. For example, if you want to change the default or widget index, you have to click through the entire tree again after each save.

For example:

Expected behavior

If you make a change to a variable or other changes (metadata, etc.), the entire tree should remain open

Steps to reproduce

See attached gif.

Your environment

OpenHab:
Proxmox LXC (Proxmox 8.2.2)

Linux Distribution:
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian

Tested with:
Windows 10
Opera 112.0.5197.53

Reproduced with
Firefox: 129.0.2 (64-Bit)

[Boldfor]

Noticed this as well (though not specific to 4.2.1). Happy to test as well.

[CappuccinoCake]

+1 for me

[MichaelEimke]

I've noticed the same issue on my OpenHAB 4.2.2 instance. Interestingly, at least here, there's no need to change or save anything but it already occurs after entering an items property view (by clicking on the item in the right panel) and then going back to the model view using the provided "back" button. The item then stays selected (properties are still visible in the right panel), but the tree view refreshes and changes to collapsed state.

[calle2010]

As a workaround, I expand the whole tree using the button on the upper right and then filter the items I want to see, which usually is possible by part of the name (e. g. "kitchen"). The tree stays open in the expanded state and the filter is still applied.

[FROeHlyEisvogel]

Same issue here with openHAB 4.2.2 but also noticed it some versions before.

[j-simian]

+1 in 4.3.2. I may give this a go if I find some time as it seems like a small feature (I've not worked with openhab/vue before, but this sounds like a case of just throwing the state of folded/unfolded nodes into localstorage and loading that on refresh)

[mherwege]

This should be solved with #2970, so no need to create a separate PR.