[email] Implement locally stored email drafts saved from the compose card

RESOLVED DUPLICATE of bug 838012

Status

Firefox OS
Gaia::E-Mail
RESOLVED DUPLICATE of bug 838012
5 years ago
5 years ago

People

(Reporter: maat, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: interaction [UX-P1], [TEF_REQ], PRODUCT-FEATURE)

(Reporter)

Description

5 years ago
There is no facility for end users to save emails that they are composing as drafts. This is expected 'out of the box' functionality for end users and its omission severely impedes the viability of the current email application.
(Reporter)

Comment 1

5 years ago
Feature required for TEF build
Depends on: 796674, 799822
Whiteboard: interaction [UX-P1]
(Reporter)

Updated

5 years ago
Whiteboard: interaction [UX-P1] → interaction [UX-P1], [TEF_REQ]
(Reporter)

Updated

5 years ago
Component: General → Gaia::E-Mail
QA Contact: nhirata.bugzilla

Updated

5 years ago
Whiteboard: interaction [UX-P1], [TEF_REQ] → interaction [UX-P1], [TEF_REQ], PRODUCT-FEATURE
It is my understanding that this is a desired feature for leo, so requesting leo? so we can make it official.

The best discussion of the issue, and indeed a decision that needs to be made, can be found on the IMAP child bugs about this (we have 1 for activesync and 1 for IMAP for legacy reasons):
https://bugzilla.mozilla.org/show_bug.cgi?id=799822#c5
blocking-b2g: --- → leo?
Blocks: 838012
Bug 838012 is a leo+ user story on this bug; clearing leo? on this bug.  I'm making this bug more specifically be about implementing local persistence of composed draft messages so there's no ambiguity.  We will be able to implement bug 796674 and bug 799822 as follow-ons (with some overlap between them); I'm not inverting the deps to be blockers yet because I dislike bug-spam, but we'll eventually want to do that.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
blocking-b2g: leo? → ---
Summary: [Email Meta] End users cannot save draft emails → [email] Implement locally stored email drafts saved from the compose card
Is this required to fix bug 838012? If so, it should block.
Dietrich, yes, this is required to fix bug 838012.  That bug is just a user story bug.  I assumed we would just land on its authority since it is already blocking.


Impl howto:

We create a synthetic folder to store the drafts in.  We mark it as a new type, 'local-drafts' which we also add a new localized string for just how we have a string for 'Drafts' folders.  Because our sort order for folder is hierarchy aware, it's important that we put our local drafts folder at the same level of hierarchy as the real drafts folder.  To this end, we only want to create the local drafts folder after a successful syncFolderList so we can use the same parent.

By synthetic, I mean that it has no corresponding server on the folder.  We use a sentinel value for the serverId on ActiveSync and the equivalent on IMAP so that when we try and synchronize the folder with the server we immediately declare success without actually trying to the server.

On the front-end/UI, we have it notice when it's dealing with a local-drafts folder and handle it specially.  Specifically, when a user taps on a draft message, rather than calling getBody and displaying the message reader card, we call editAsDraft and display the composer card using the MailComposition object returned.  Of course, the editAsDraft needs to be filled out.


Follow-ups:

We will want to implement periodic time-based saving of the draft when dirty as discussed on bug 838012.
Assignee: bugmail → etienne
Assignee: etienne → nobody
consolidating to the user story bug to reduce uplift confusion
No longer blocks: 838012
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
No longer depends on: 796674, 799822
Resolution: --- → DUPLICATE
Duplicate of bug: 838012
You need to log in before you can comment on or make changes to this bug.