Before, old conversations that were left still occurred in the list (only adding+updating was done, but never deleting)
also, the list is up to date when coming back from chat. Otherwise there may be unread messages shown for a short moment which were already read.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
To support federated rooms, capabilities have to be checked from the room which now also has capabilities.
If room is not federated, capabilities fromuser are still checked.
This is why CapabilitiesUtil had to be refactored to accept SpreedCapabilities which can come from room or user.
Other than that, many other changes were made as a result of this change.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
sending too much data via intent always is a bad pattern which can lead to TransactionTooLargeException.
When OpenAI translation is enabled, the capabilities contain a ton of translation combinations. These capabilities are contained in 'currentUser' as well in 'selectedConversation'. So, TransactionTooLargeException was thrown.
this PR:
- avoids passing too much data as parcelables in intents (esp. conversation and user)
- introduces MVVM patterns to load required data (esp conversation) from backend (for now via requests, in the future from database first)
- introduces ConversationModel which is created out of the Conversation json model
- loads user data via injection when possible
- creates some quickfixes in ConversationBottomDialog, EntryMenuController and OperationsMenuController.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Because of "supported-reactions" and "predefined-backgrounds" the capabilities cannot be parsed with
`var config: HashMap<String, HashMap<String, String>>?`
As a result it was not possible to login into the app.
This is now
`var config: HashMap<String, HashMap<String, @RawValue @Contextual Any>>?` while always checking for the type when accessing the values.
"supported-reactions" and "predefined-backgrounds" are not handled yet.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This is to work around a race condition where this class would asynchronously overwrite other user attributes
with old values after a user switch.
Co-authored-by: Marcel Hibbe <dev@mhibbe.de>
Signed-off-by: Álvaro Brey <alvaro.brey@nextcloud.com>
i was able to see that the loop was somehow interrupted during debugging which caused two users to have current =true
this should avoid the problem with the loop.
anyway, this doesn't seem to solve the issue completely as i was able to reproduce it again with the new solution. so maybe there are still more methods/scenarios which can cause this.
additionally, i managed to have all users to have current =false with this new query (while switching accounts very fast and often in ChooseAccountDialogFragment..)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
just refactoring for now. this doesn't solve the bug!
Problem that needs to be solved:
When adding a new Account (User), it is marked as "current", while for the other logged in users "current" must be unset (-> disabled).
The problem is, that for the old active user, "current" is not unset so there were multiple accounts marked as "current".
In the ChooseAccountDialogFragment, only one of the current accounts is shown at the top. Below the set status field, all accounts are listed that are not marked with "current". So as a result, there can be accounts hidden that were marked as "current".
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
