We used to add app the member counts of invited users and joined users,
which would make us assume the participants list is complete. Which
would mean we always return the wrong state.
Additionally there is no need to rely on if we have a cached response.
Instead we always only check for completeness instead of possibly
returning stale responses just because we fetched the members once.
We now handle state in the correct order in the sync handler. Using the
timestamp lead to false results when we still generated a default
timestamp of "now" for events, however even without that state events
can have an older timestamp like when accepting an invite on a server
with the clock behind by a minute and we should instead rely on the sync
handler giving us state in the right order.
This creates a set before
requesting users from the
database. This prevents
doing the same check for
the same user multiple
times and also prevents
concurrent modifications
of the event list.
This creates the timeline object
earlier in the Room.getTimeline() method.
This results to that the
Timeline object already starts
to listen on the event stream
while the getTimeline() method
requests users from the database
and tries to decrypt room
events. I assume that this
causes the problem that
on timeline creation new
events get lost because they
come in, while getTimeline() is
not yet completed but the
onEvent stream is not yet
connected at the same time.
This refactors three methods
regarding powerlevels. It
makes them a little bit more
readable and removes
unnecessary checks. it
also changes the canSendDefaultMessage
method in a way that it also
checks the events map in the
powerlevels so that it returns
true if message events are
overwritten there. It also
improves the dart docs and
explains in more detail what it
does.
BREAKING CHANGE: This changes the runInRoot method to not return a
future. As a user, if you need the result of an async computation passed
to runInRoot, please await it directly. Also the KeyVerification start
and a few call methods now return a future.
At least in our CI this throws a null assertion error and since we
explicitly expect this to sometimes be null in our code, we should store
it as such.
It wasn't quite obvious that invites were always sorted at the top, if
you just looked at the sort function. This makes it more explicit and
also makes invites always sort before favourited rooms.
If we join first, it is possible that our member event is not the invite
event anymore. As such we should fetch that state first, before joining.
But also there is little reason not to mark the room as a DM
immediately. That prevents the room from temporarily becoming a group
room, that might be visible in the UI temporarily.
fixes https://gitlab.com/famedly/company/product-management/-/issues/1006
You can either set them to private on the client or overwrite the
behaviour for that on each readMarker call. This also handles incoming
thread receipts and tries its best to figure out what is the latest
receipt. This however breaks the old m.receipt account data event.
fix: implement activeGroupCallEvents to get all active group call state events in a room
refactor: move staleCallChecker and expires_Ts stuff to an extension on Room, instead of Voip because it makes much more sense per room rather than on voip, also makes testing easier
fix: populate local groupCalls list on instantiating VOIP()
fix: starting stale call checker is now handled by the sdk itself because clients can forget to do so
This fixes a bug that the
last message was sent
incorrectly when a session
key received for example
from the key backup. It may
fix several issues like the
last message is set as a
very old one or the last
message is not decrypted.
This deprecates the displayname
getter in favor of the new
getLocalizedDisplayname which
gets the default localization
by default so it can be
called without defining localizations. It adds a method
to calculate if a room is an
abandoned DM room where
it is made sure that the room
is actually empty.