cinnyapp
rooms that have been replaced still show up in room list
Describe the bug
now that cinny has a better user flow for rooms that have been upgraded, it is also rendering the old room separately from the new room. this means that unless you leave the old room (thus making its contents inaccessible) you will have redundant room lists.
Reproduction
- join/create a room
- upgrade the room using another client
- join the upgraded room
- there are now two rooms with the same name in your room list, one which has been tombstoned and the replacement.
this can be especially confusing if the room is part of a space, as the old room will be removed from the space. so both rooms will exist, the old room listed in the "Home" navigation category and the new room found under the space appropriately.
Expected behavior
the old room should not be in the room list, but should be accessible only through the new room's settings to browse for historical purposes. it should for all other intents be considered "replaced" in the user interface by the new room.
Platform and versions
linux, firefox, cinny 3.0.0
Additional context
No response
This is intentional as previously there was not any easy way to leave them.
Now you can leave them and join from the start of new room.
hmmm. ok, i guess that makes sense, it's just contrary to how element handles it but i'll run with it for a bit.
ah, i just left my test room, and then clicked the button to "Join old room" to see it, and i cannot because it was invite-only. so there's no way to regain access to any data in that room this way.
i guess i expect the behavior to align more closely to the "recommended" behavior of the spec:
Clients which understand m.room.tombstone events and the predecessor field on m.room.create events should communicate to the user that the room was upgraded. One way of accomplishing this would be hiding the old room from the user’s room list and showing banners linking between the old and new room - ensuring that permalinks work when referencing the old room. Another approach may be to virtually merge the rooms such that the old room’s timeline seamlessly continues into the new timeline without the user having to jump between the rooms.
Would it be a solution to this UX problem to have a special section in each space / the rooms list for rooms (a) with an m.room.tombstone event, and (b) where you also joined the new one?
That way, you don't need to leave them, which might be undesirable for retaining the history, and still not having them clutter the view.
Due to condition b, this should also not negatively impact the discovery that there is a new one.
As of v4.9.1 at the latest, Cinny already places a link to the old room at the top of the new room
and in the old room it provides only a link to the new room instead of being able to send messages.
So if someone really wants to leave the old room they can still navigate to it from the current room. So it really should hide the old rooms completely from a user's room list.
And Spaces have a similarly undesirable behavior. If Space is upgraded, then you now have two copies of the Space, and if the rooms within the space are upgraded too (order of operations might matter, but however I did it is how this has ended up), there's now the old Space with the new rooms, the new Space with the old room, and the new rooms which are just filed under Home, as if they aren't in a space at all. Upgraded Spaces in Cinny already have a link back to the old space if need be
So I really don't see a need to persist the legacy space in a user's list either.
Element fixes these anomalies though the recommended behavior of the spec, there is only one Space, the upgraded version, in the advanced tab of the Space settings you can View older version of <Space Name>. Then each of the rooms are in the new Space, the current upgraded versions only, with a message at the top of the room timeline indicating that it's an upgraded room and how to get to the archived version.
This is the behavior I would expect other up-to-date clients to emulate.
