* Put a cancel button on the first page of the create key backup
dialog
* Move settings logic into the room reminder: I know this is moving
logic *into* a view but RoomView is quite heavyweight as it is.
* Give the recovery reminder an explicit 'onDontAskAgainSet' rather
than onFinished which was getting called with false when the last
screen of the dialog was closed with the cancel 'x' rather than
the 'close' button.
https://github.com/vector-im/riot-web/issues/8066
If the current device hasn't verified the device that created the account's
current key backup version, then the current device is won't use the key backup.
This change adjusts an existing in-room reminder to do the right thing for this
case by allowing the user to verify the device that created the key backup.
Fixesvector-im/riot-web#7902.
This adds an in-room reminder above the message timeline to set up Secure
Message Recovery so that your keys will be backed up. If you try to ignore it,
an additional dialog is shown to confirm.
Fixesvector-im/riot-web#7783.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
make mx_fadable not do anything anymore, and make room settings
full size.
Room settings haven't been designed yet, so all of this will
have a full pass when we have a go at it.
This ends up being translated to ?server_name= in the matrix-js-sdk, although that has a bug at the time of writing. It converts `server_name: ['a', 'b']` to `?server_name=a,b` instead of `?server_name=a&server_name=b`
For reference: the `viaServers` option is routed through the 'join_room' action to RoomViewStore#_joinRoom which is passed directly to the js-sdk http-api#joinRoom function.
Next steps:
* Fix the js-sdk parsing
* Make the SDK generate matrix.to links with ?via=
_loadMembersIfJoined is called from
_onRoomLoaded < _onRoomViewStoreUpdate, before incoming state
from the store is applied to this.state, so looking up the room
with this.state.roomId doesn't always work, which would cause
the members not to be loaded. Pass in the room instead.
This is more reliable with LL enabled as the syncing user is
only known when it was active in the current timeline
or when the members have been loaded
when peeking, the members weren't being loaded at all because
the room wasn't available yet,
and the need for loading the members was never re-evaluated after that.
This only loads the members once the user has joined the room,
which also helps to avoid load all the members before an invite
is accepted.
checkIfAlone() filters the whole member list, which is fine until
we do it once for every membership event, then we have an n^2
problem. Move it into the rate limited function.
Fixes https://github.com/vector-im/riot-web/issues/7163
stopPeeking is currently not called when navigating to a joined room
after having peeked a room. This causes the /events endpoint for the
peeked room to be called until peeking another room, even when not
viewing the peeked room anymore.
The current code would only stop peeking if you joining were true (note the nesting),
e.g. when waiting for your join to be confirmed by /sync.
This change might make stopPeeking called also when not needed by there is a guard in
that method to do nothing if not currently peeking.
* Show a spinner while we wait for widgets to be deleted
* Hide widgets while they're pending deletion
* Don't put another jitsi widget into the room if there's already
one pending
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
Whilst testing various DM paths, @lukebarnard1 found that there were
many failures to add the room as a DM against the correct user. It
turned out most of the failures seen were because the user chosen
was the current user. If the user accepted an invite it would often
be marked as with themselves because we chose the sender of the
join event as the DM user.
This fix makes the DM room setting process the same for both the
inviting client and the invited client. A RoomState.members
event causes the DM room state to be set in the room, regardless
of whether we are currently `joining` (see previous impl.)
The two cases for setting a DM are:
- this user accepting an invite with is_direct
- this user inviting someone with is_direct
This should handle all cases for setting DM state.
