Closed
Bug 834646
Opened 11 years ago
Closed 11 years ago
[email] Implement locally stored email drafts saved from the compose card
Categories
(Firefox OS Graveyard :: Gaia::E-Mail, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 838012
People
(Reporter: maat, Unassigned)
Details
(Whiteboard: interaction [UX-P1], [TEF_REQ], PRODUCT-FEATURE)
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•11 years ago
|
||
Feature required for TEF build
Reporter | ||
Updated•11 years ago
|
Whiteboard: interaction [UX-P1] → interaction [UX-P1], [TEF_REQ]
Reporter | ||
Updated•11 years ago
|
Component: General → Gaia::E-Mail
QA Contact: nhirata.bugzilla
Updated•11 years ago
|
Whiteboard: interaction [UX-P1], [TEF_REQ] → interaction [UX-P1], [TEF_REQ], PRODUCT-FEATURE
Comment 2•11 years ago
|
||
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?
Comment 3•11 years ago
|
||
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
Comment 4•11 years ago
|
||
Is this required to fix bug 838012? If so, it should block.
Comment 5•11 years ago
|
||
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
Updated•11 years ago
|
Assignee: etienne → nobody
Comment 6•11 years ago
|
||
consolidating to the user story bug to reduce uplift confusion
You need to log in
before you can comment on or make changes to this bug.
Description
•