Remove the dialog that asks whether to save the draft or not and save
the draft automatically when there are changes in the composer. After
saving it show a snackbar that the draft has been saved and offer an
option to move the draft to trash from the snackbar.
MAILAND-2832
Instead of fetching verification keys asynchronously and re-launching decryption
after they are ready, we block the decryption until the keys are fetched.
Also fixes the data transfer between the signature verification process and the
UI for the lock icons.
MAILAND-2046
If the invitation messages has an answer, it `header` will be `null` and it will not be possible to extract the recipient; in that case we, search in the `toLost` for find an address that matches one of the currently primary user's
MAILAND-1585
The issue is that when a message gets deleted, even though that action
returns the user to the mailbox, the view model isn't destroyed on time
and it keeps observing the message in DB. So, when the message is
deleted optimistically from the DB, the observer triggers the getMessage
method which tries to fetch the message again and most of the time
succeeds because the action is not yet registered on the API side. The
fix includes canceling the Job of the Flow which observes and emits the
changes to the message/conversation when the delete action is triggered.
MAILAND-1834
This is to make sure the change is reflected optimistically in the mailbox list when we perform the delete action on a message and we are in conversation mode.
MAILAND-2284
- The third parameter when calling moveMessagesToFolder in moveLastMessageToTrash in message mode was wrong (the current location of the message).
- Remove the condition that checks whether a conversation has more than one message when performing actions from the bottom action bar in the details screen.
MAILAND-2284
As we have agreeded that we should schedule workers from the repositories this commit moves the calls of message labels workers to label repo, also moves MoveMessagesToFolder to mailbox as it is not direcly labels related.
MAILAND-1525
This should mitigate the NPE generated in the mentioned tickets. This should be happening when embedded images are downloaded when the Activity is already closed, so ignoring the absence of value and terminate the process would not negatively affect the users.
Worth to mention is that this should not be happening in a sane LifeCycle, as the `viewModelScope` should be already cancelled when this is happening
MAILAND-2332
MAILAND-2394
This solution is similar to the previous approach however is a little more correct
in the naming and what it does- we don't want to mark a message as read if it is not
visible to the user, as it could not possibly be read by them.
MAILAND-2339
The issue was caused by the following sequence of events:
- message is marked as unred,
- this leads to the details view being closed and mailbox view being shown,
- in the meantime, the message is marked as unread in the local db which leads to new emission,
- there is a time window where the detail view activity is still not destroyed and receives the event
with the message, unread, being emitted, even though the view is no longer visible to the user, and
marking this message as read again.
The solution is to ignore the emitted messages/conversations after the details activity has been paused-
this way the unread message will not be incorrectly marked as read when the user is already seing
the mailbox activity.
MAILAND-2339
Changed the way in which the conversations are loaded from the user's perspective:
- show spinner until the whole conversation is loaded (in order to avoid showing only some
messages that have already been cached in memory),
- show the subject while the data is still loading for a better user experience
Additionally did a small cleanup of the MessageDetailsViewModelTest class.
MAILAND-2334
This is needed to avoid an inconsistent state where, till the next
"event" is received all the messages of a conversation that has just
been starred or unstarred would have an updated "isStarred" flag but
out-of-dated "labels" (which would still reflect the previous starred
status.
Within other things, this was causing the UI to be refreshed when the
event with the correct labels was retrieved.
MAILAND-2291