- Add the edit action in the room details
- Add "Add topic" button in room details
- Add the screen behind that action to edit some room properties: avatar, name, topic
- Handle the save button action
- enable the button only if changes are detected
- display a loader "updating room"
- display an error dialog if any request has failed
- Check user has the right power level to change various attributes
- "Add topic" is only shown if there's no topic and they are able to set on
- Edit menu is only shown if they can change topic, name or avatar
- On the edit page, any fields they can't change are uneditable
Co-authored-by: Chris Smith <csmith@lunarian.uk>
Invite users to existing rooms
Scope:
- Allow inviting from the room detail screen and the member list
- Invite option is only shown if the user has the correct power level
- Search flow the same as creating a new room, allowing multi-select
- Existing room members/invitees are disabled with a custom caption
- Sending is asynchronous, an error dialog will appear wherever the
user is if necessary
Closes#245
Splits a Room's member list in 2 showing pending invitees first and then the actual room member.
This simple user facing change entails a host of under the hood changes:
- It copies the logic from the `userlist` module and merges it into the `roomdetails` module removing all details not related to the member list (e.g. gets rid of multiple selection, debouncing etc.).
- Uncouples the `roomdetails` module from the `userlist` one. Now leaving only the `createroom` module to depend on the `userlist` module. Therefore the `userlist` module could be in the future completely removed and merged into the `createroom` module.
- Changes the room members count in the room details screen to only show the members who have joined (i.e. don't count those still in the invited state).
Missed ACs:
- This change does not make the member list live update. Discussion is ongoing on how to make this technically feasible.
Parent issue:
- https://github.com/vector-im/element-x-android/issues/246
Fix a few FFI leaks
These are instances where we obtain an FFIObject and don't call
Close on it to release the underlying reference on the Rust side.
The worst instance here was leaking an object per room member
every time we refreshed the member list
