For setting:
- name
- topic
- history visibility
- power levels
Testing RoomSettings required more stubbing on the matrix client.
The power level tests should be failing at this commit, with
fixes being made in upcoming commits.
Some tests are marked as known failures that we should fix but
aren't necessarily bugs:
- SettingStore.setValue is used when saving despite the user not
having made a change.
- Testing directory publicity changes cannot be tested because we
update state asynchronously in componentWillMount (which we do
not block on in beforeEach).
Also, we needed to use `export default` to make sure everything
uses the same client peg and client.
Previously we assumed that a decrypted event has a room_id
but this isn't necessarily true for to_device events.
It makes sense to ignore events that aren't associated with
rooms anyway given that the list we're updating only contains
rooms!
To make sure that we handle rooms that our
client has not seen previously, we regenerate
the room list when the room is stored -
which is indicated by the js-sdk by the
Room event.
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.
ensures that https://scalar.ve can't access the API.
many thanks to @rugk for pointing out the potential vuln.
cc @rxl881 in case this bug has been transplanted elsewhere.
so that we can do reorderings of lists ordered by most recent event.
No optimisations here; we only update for timeline events
on live timelines that could update the "unread count".
so that they can be dragged and dropped
without interacting with each other, as
they would do if GroupView contained
one droppable to contain them all.
Luke Barnard