799829 - [email] implement move/trash 'do' implementations and supporting infrastructure

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

Description

[Andrew Sutherland [:asuth] (he/him)]

Complete implementation of IMAP move and delete-as-move-to-trash.  This was previously tracked on https://github.com/mozilla-b2g/gaia/issues/2531 and has had previous steps landed.  (Move is complex in terms of potential data-loss and offline semantics, so it led to a lot of important groundwork for offline operations and resiliency improvements.)

I am actively working on/finishing this up now.  Formal blocking tracking would be appreciated, although it's already been explicitly indicates that move/delete is viewed as very important for dogfooding (which is why I'm working on it.)

Without this, we have no message moving (the UI is a NOP without this), and the current implementation of deletion on IMAP will continue to be both misleading (the UI is not updated, but the \Deleted tag is sent to the server) and potentially data-lossy (no move-to-trash occurs).

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

squib, as a heads-up, I have just started normalizing a fair amount of the job implementation between IMAP and ActiveSync which should put them both on the same footing.  The main thing for you to avoid is trying to refactor _do_crossFolderOp since Iin other patches  am restructuring it somewhat.  The main negative performance/efficiency fallout is that if we have operations that span multiple folders, rather than issuing a single mutation request to the server that batches all of those, we will end up issuing one request per folder.  This is a combination of a limitation propagated from IMAP where connections can only be in one folder at a time and a desire to only hold one folder mutex at a time when possible for hygiene reasons.  An efficiency improvement we could put back in later would be to not send the actual request until we finished traversing all the folders, but it's nice to be able to update the SyncKey.

I need to see what fits the code ergonomics, but I think this may also entail pushing some of the protocol specific stuff from _do_crossFolderOp into the ActiveSyncFolderConn impl.

I'll reference a commit once I've got this going and have smoke-tested it not breaking hotmail.

NB: This builds on top of changing the GUIDs to be stored in 'srvid' which is required for offline speculative moves which is a case where ActiveSync is in the same boat as IMAP unless we can assume that the server-issued GUID will be the same in the target folder of a move which we are not assuming.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

squib, while refactoring the jobs stuff, I've noticed that my modtags requests on a hotmail account are getting actual synchronization data coming back that's happened since the last sync.  Specifically I am seeing an 'Add'.  This is not surprising given that the manipulation is happening inside a Sync command, but it does complicate things a little.  Should I just have modtags try and just be a sync operation that also injects some commands at the same time?  It's not immediately obvious whether the output of the command is varying from when we add all the other flags.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Final pull request up at https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/64

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

This has been merged to gaia/master:
https://github.com/mozilla-b2g/gaia/commit/1dcc50392fb746cd29a61e4c302c746347d81609

Bug 804904 has been spun-off to capture the need to implement the error-handling and undo variants of the operation.  Currently, in the event of failures running the move operation against the server, we will set the operation to a 'check' state which will declare the operation moot when it runs against the server.  This will result in the operation never being run against the server, resulting in the locally applied operations being undone once we synchronize the relevant folders against the server.

Bug 804909 has been created to capture the discovered problem with the lack of a message-id header or references headers breaking our threading from the perspective of recipients.

Comment 5

[Mila Davydova]

Verified with Unagi, build ID: 20130112070202
User is able to delete messages (move to trash folder). The notification tag with the number of deleted messages is displayed and messages are moved to a Trash folder.