* Report shortcut usage for outgoing messages
This patch adds support for creating and pushing dynamic
long-lived shortcuts for outgoing messages. This together
with an existing reference to the roomId used by the
shortcuts as an identifer allows conversations to be
prioritized.
See https://developer.android.com/training/sharing/direct-share-targets#report-usage-outgoing
* Simplify how to get the other user in a DM room
* Add initial avatar icons to shortcuts
* Remove room shortcuts when they're no longer joined
* Try using API 33 for the new tests. They worked locally with API 30, so it's weird the CI asks for a higher API version.
* Add observers for the pin code and session logout states. With this we can prevent new shortcuts from being created and remove existing ones when needed.
* Wrap all calls to `ShortcutManagerCompat` with `runCatchingExceptions` to avoid crashes
* Make `DefaultNotificationConversationService` a singleton.
---------
Co-authored-by: networkException <git@nwex.de>
Co-authored-by: ElementBot <android@element.io>
* Initial threads support: parse `ThreadSummary`.
Replace several `isThreaded` values with `EventThreadInfo`, which contains the info about the event either being the root of a thread or part of it.
* Add `Threaded` timeline mode
* Add a `liveTimeline` parameter to `TimelineController`'s constructor. This way we can customise which timeline will be used as the 'live' one. Also add `@LiveTimeline` DI qualifier for the actual live timeline of the room.
* Create `ThreadedMessagesNode`. Allow opening a thread in a separate screen.
* Add the callbacks for the list menu actions - even if they're the wrong ones and will send the data to the room instead
* Send attachments and location in threads
* Fix polls in threads, add support for sending voice messages in threads
* Display thread summaries only when the feature flag is enabled
* Use 'Reply' instead of 'Reply in thread' when in threaded timeline mode
* Remove incorrect usage of `Timeline` in `MessageComposerPresenter`. This led to replies to threaded events not appearing as actual replies.
---------
Co-authored-by: ElementBot <android@element.io>
* Move `ChangeRoles*` classes to their own module so they can be shared
* Hook the change roles screen to the leave room action, add confirmation dialogs
* Use enum instead of sealed interface for `ChangeRoomMemberRolesListType`
* Try to improve communications between nodes
* refactor (leave room) : makes sure to expose only necessary code from api module
* Add `:libraries:previewutils` module to share some test fixtures used for UI previews
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
Co-authored-by: ganfra <francoisg@matrix.org>
* Replace `RoomMember.Role.CREATOR` with `RoomMember.Role.Owner` - Make `RoomMember.Role` a sealed interface instead
* Adapt room member role mapping to include the power level to distinguish between admins and owners
* Use new `RoomMember.Role` sealed interface through the app
* Change how `MembersByRole` groups members to add owners to the admins section
* Adapt the `ChangeRoles` screen to the new roles:
- Owners can't modify other owner's roles.
- They can modify the roles of any other user, without confirmation.
* Adapt 'roles and permissions' screen:
- Owners can't demote themselves.
- The admin count also counts owners.
* Add more tests and screenshots
* Add owners to its own section in the 'change roles' screen
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
* Update dependency org.matrix.rustcomponents:sdk-android to v25.7.23
* Adapt to SDK changes:
- Add 'creator' role, adapt existing logic to it.
- Remove `ReplyParameters`, replace with `EventId` where possible.
- Fix changes in OIDC auth methods.
- Add more join rules.
* Make sure both creators and users with power level >= 150 are displayed as 'owners' in the room member list.
* Don't close the roles and permissions screen if the user is a creator
* Use `MediaPreviewValue.DEFAULT` for `MediaPreviewConfig.DEFAULT` too
* Improve APIs around checking roles and power levels:
- Ensure `RoomInfo.RoomPowerLevels.users` can't be directly used to check power levels since it can't check the power levels for creators.
- Add a few helper functions to handle actions that relied on the previous `users` property, and docs to explain their usages.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
Fix broken API changes:
- `RoomInfo.isPublic` is now optional, so we need to assume its default value in some places of the app.
- `RoomInfo.userPowerLevels` is now `RoomInfo.roomPowerLevels` and also contains this info.
- `ClientBuilder` now uses a `DecryptionSettings` value.
- The call widget settings provider now internally uses a different Rust type.
- `Client.clearCache` now takes a `syncService` so it can stop it.
---
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
