Closed Bug 796674 Opened 12 years ago Closed 12 years ago

[email/activesync] Allow saving drafts

Categories

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

defect

Tracking

(blocking-basecamp:-)

RESOLVED INVALID
blocking-basecamp -

People

(Reporter: ghtobz, Unassigned)

Details

(Whiteboard: interaction, UX-P1, testrun 2, PRODUCT-FEATURE)

[GitHub issue by mozsquib on 2012-09-18T16:58:32Z, https://github.com/mozilla-b2g/gaia/issues/4870] We can't save drafts over ActiveSync. This might be a little bit tricky, since there's not a built-in function to do so; maybe we can just push the MIME over in a sync command? This is probably complicated by the fact that we want to overwrite old versions. Also, I'm not sure if we have this hooked up for IMAP yet. @asutherland?
[GitHub comment by asutherland on 2012-09-18T17:08:43Z] It's not hooked up for IMAP no, but the idea is to use APPEND for IMAP, and an append operation is already implemented. I'll file the IMAP variant of this issue too.
[GitHub comment by asutherland on 2012-09-18T17:11:42Z] Oh, this already exists as #2482 for IMAP
Component: Gaia → Gaia::E-Mail
https://github.com/mozilla-b2g/gaia/issues/2482 Was set to blocking minus... there's no way to get to your drafts once it's composed.
Priority: -- → P3
blocking-basecamp: + → -
For a UX PoV the ability for the end user to save an email as draft is an integral and ubiquitous part of the email usage experience. This is especially the case when there is a 'Drafts' folder contained within the draw that is presented under the 'folder' icon, which is the case when all email accounts i have tested with are synced. Bottom line is that end user expectation is set and fossilized that emails can be saved to draft by previous long term interaction with their email accounts on other platforms. We also reinforce that expectation by allowing a drafts folder to be created upon sync. We simply cannot have a viable launch for the email app without this functionality I am going to raise this as a UX P1. putting Josh on CC to take this bug into tirage asap.
Flags: needinfo?(jcarpenter)
Whiteboard: [label:email][label:feature] → interaction [UX-P1]
I agree that losing anything the user has painstaking typed into their touchscreen keyboard is a capital sin of mobile UX, and that we should prevent it be one means or another. Chris, based on your blocking-, I take it there is a Product call to remove email Drafts from v1 scope? Casey, can provide any background info?
Flags: needinfo?(jcarpenter) → needinfo?(kyee)
Whiteboard: interaction [UX-P1] → interaction, UX-P1
Unagi, build ID 20121217070202 Email doesn't get saved in Drafts folder after user opts out, while composing a new email massage. After tapping on "back" button user is given only 2 options: "discard" and "cancel".
I agree that from a UX perspective this is not the ideal behavior. It was decided in a discussion with Product that it should be deferred for V1 due to the high-effort and risk.
Flags: needinfo?(kyee)
Whiteboard: interaction, UX-P1 → interaction, UX-P1, testrun 2
Still Repros on Unagi device Build ID: 20130115070201 using the December 5th kernel v 1.0.0-Prerelease
Blocks: 834646
Whiteboard: interaction, UX-P1, testrun 2 → interaction, UX-P1, testrun 2, PRODUCT-FEATURE
No longer blocks: 834646
Ok, I've looked through the documentation for ActiveSync, and this is impossible. According to MS-ASCMD: "The Add element cannot be used to add any email items from the client to the server..."[1]. MS-ASEMAIL has more details, none of them encouraging: "Email namespace elements that are child elements of the airsync:ApplicationData element when the airsync:ApplicationData element appears within the airsync:Add element in a Sync command request are not used to synchronize E-mail class content; instead, those elements are used to synchronize SMS class content."[2] That is, you can use the Email elements to create new SMSes on the server, but not new emails. Likewise, updating the bodies of previously-saved drafts is impossible: "The following E-mail class elements can be child elements of the airsync:ApplicationData element when the airsync:ApplicationData element appears within the airsync:Change element in a Sync command request: Flag (section 2.2.2.27), Read (section 2.2.2.47) Categories (section 2.2.2.9)".[2] Finally, I'm not sure what the current state of Android/iOS's support for saving drafts on ActiveSync is, but 1) the Android code I've consulted has nothing in it to allow saving drafts to the server, and 2) Apple's support page says "Note that the Exchange ActiveSync protocol does not permit saving drafts created on the iOS device back to the drafts folder on the Microsoft Exchange Server.".[3] With all this in mind, and the fact that we now have a local drafts folder, I think we should close this bug. [1] http://msdn.microsoft.com/en-us/library/gg675487%28v=exchg.80%29.aspx [2] http://msdn.microsoft.com/en-us/library/ee219087%28v=exchg.80%29.aspx [3] http://support.apple.com/kb/HT2124
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.