b/11294681
The problem is that when we try to open an attachment for a
message in search results, it fails. The reason is that part of
loading the attachment, we need to open the remote folder the
message is in. For search results, the message's mailboxKey is
the special fake "search_results" folder, which doesn't actually
exist on the server.
For this change, I've added a new column called "mainMailboxKey".
For search results, this column will be populated with the real
mailbox the message is in. It will be blank for other messages.
This is a quick and low risk fix for this bug, but it's kind
of awkward. We would prefer to do one or both of the following
some time after MR1.
1. Make the "search_results" folder be a virtual folder, the same
way that unread, starred, and other virtual folders are. For these,
there is actually no mailbox row in the database, just some
queries that check various flags in the messages and behave
like folders in the UI. The messages actually still reside in the
real folders.
2. Remove the requirement to open the folder at all to load the
attachment.
Change-Id: I825ab846f78bf8b041a5d1d579260dc5d7b4c522
b/11294681
b/11325976
The problem is that when we get a message as part of a search
result, we'll end up deleting that message from the inbox (or
whatever folder it's currently in). This is because there is
a trigger that deletes messages if a new message is inserted
that has the same serverId and account.
Now, messages with duplicate serverId/account combinations are
allowed if one of the messages is in a SEARCH type folder.
Also, make a change so that when a message comes down in
a search result, we do also copy it into the primary mailbox
that message resides in, we only add it to the SEARCH folder.
Prior to this there was some code that intended to put
the search result message into the regular mailbox it's supposed
to be in, so that we'd have correct state in that message.
Unfortunately, there are several problems with this:
1. The code didn't work, it would make a copy in the regular
folder, and then unconditionally move it to the search folder.
2. If we leave this code in place, putting the message
temporarily into the regular folder still activates the duplicate
message deletion trigger, wiping out the original copy, even with
the update to the trigger.
3. It's unclear that it's even desirable to load the search
result message into the regular folder. It could be a very old
message that would not have been synced before, leaving a large
gap in your inbox, which is confusing and could interfere with
IMAP syncing.
Change-Id: I34671a3b677ab42a3efd0d170a6ebd9246ec493d
Handle the following edge cases when a manual refresh is triggered:
* No connectivity
* Low storage space
* Timeout (sync not started)
Bug: 11241113
Change-Id: I580235d633fcb65999c0bfe8bf383c9c8ba72110
b/11224731
There is a problem in ImapService.processPendingUploads().
It was trying to process updates to existing messages
as uploads. This is wrong, it means that marking a sent
messages as Read can cause it to be uploaded again,
resuling in a new message being created.
Change-Id: I502df52a7b315daeee10c1041db8f30dbfd2c04e
