Skip to content

Fixes an issue where updating flags on a folder being opened doesn't update local folder

James Magahern requested to merge buzzert/geary:open_folder_flags_changed_fix into master

When a folder is being opened for the first time, ImapEngine.Folder.update_flags is called to refresh the flags for all the messages in that folder. When the flags are updated, the notify_email_flags_changed signal is called, which in turn notifies the conversation monitor that the flags have changed and is thus appropriately updated.

However, these flag changes are never persisted to the local database because the local folder is not updated if these flags changed. This has a bad effect for messages that are deleted since the last time you opened that mailbox, because it means if you open a folder containing messages that have the \DELETED flag set, once update_flags is called, they get evaporated from the conversation monitor as expected, however if you navigate away from that folder and return to it later, the message returns.

Steps to reproduce:

  1. Open a mailbox in the UI containing some messages
  2. Quit Geary
  3. Mark one of the messages in that mailbox as \DELETED using another mail client ('d' in mutt, sync with $, don't purge).
  4. Re-launch Geary --> RESULT: Geary launches, mailbox is refreshed, deleted message disappears (expected)
  5. Navigate to another mailbox
  6. Navigate back to previous mailbox --> RESULT: Message that was deleted has returned.

This patch simply ensures set_email_flags_async is called on the local folder if the remote list operation indicates there were flags that have changed, thus ensuring the flag changes are persisted to the database. Normally this happens with an imap-replay-operation, but since this was an explicit update call, no replay operation is scheduled.

Testing: Ran all client and engine tests, all passing on my machine.

Merge request reports