This can only happen when the app was killed by the OS and then you received some notification.
This notification action creates a new `DefaultSessionPreferencesStore` when trying to fetch `isSendPublicReadReceiptsEnabled`, which would contain a different session coroutine scope than the one created when instantiating the navigation graph (`@SessionCoroutineScope`), resulting in flows that never emit any items and close automatically as 'completed'.
This in turn prevented the timeline items subscription in `TimelinePresenter` from progressing, since we're also checking `isRenderReadReceiptsEnabled` there, which is closed and in turn closes the timeline items flow.
* Allow HS to disable encryption in Element Pro
Add `force_disable_e2ee` support in the Element well known retriever and cache to allow a homeserver to disable encrypted room creation and enabling encryption in an existing room in Element Pro clients
* Bump enterprise repo back to `main` branch
* Try fixing DM creation in Maestro
* Also handle 'invite new people to this room' with first invite to aRoomName
* Try adding a room list clean up sub-flow
* No need to press back button after successful invites
* Looks like 'hideKeyboard' works as 'back' and messes up with the navigation. Try using the workaround described in https://docs.maestro.dev/reference/commands-available/hidekeyboard#workarounds
* Default to dark theme for EC
(this is the intended design on light and dark system configuration)
* Use `theme=dark` url param for element call
* Update CallScreenPresenter.kt
* Collapse runs of deleted messages in the timeline (#7111)
* Collapse runs of deleted messages in the timeline
Collapse a run of three or more consecutive deleted messages into a single
expandable group, reusing the existing state-change grouping (the same way
element-web does it) instead of showing one "Message removed" placeholder per
deletion. The header shows the count only ("N deleted messages"); the Rust SDK
does not expose who performed the redaction, so we don't attribute it.
On by default. Runs shorter than three are left as individual placeholders, and
day dividers and read receipts are preserved (a run is broken by any
non-redacted item, so a day is never emptied).
Run the collapse as the final step of TimelineItemGrouper.group() instead of
a separate pass in the presenter, as suggested in review. Kept as its own
finalization step rather than via canBeGrouped() so the group stays all
redacted and the count-only header is preserved.
The group id is resolved through the grouper's existing id registry, like the
other groups, so it stays stable however the run grows and the user's
expand/collapse state is kept across timeline updates.
* Replace temporary strings with final ones
* Update screenshots
---------
Co-authored-by: Hi Dude! <klarkmonty@tuta.io>
Co-authored-by: manfrommedan <manfrommedan@users.noreply.github.com>
Co-authored-by: ElementBot <android@element.io>
renovate[bot]