Productivity25: As a user, I want to be able to forward emails along with their attachments to recipients to make it easier to get a received file to a contact. In bug 828294 we added a UI warning that we are unable to actually forward attachments. This bug tracks the enhancement to support forwarding the attachments.
Hi Wayne : Could you tell me that this new feature will be supported on V1.2 or more new SW?
Andrew, feel free to correct me if this is actually in, but given the bug status here I believe this is not for v1.2.
It has been reported by TEF BUs during v1.3 IOT process so adding to backlog to be properly prioritized. Thanks!
Use feature-b2g:2.2? rather than just 2.2.
It saddens me that this is getting postponed again and again, I find it "frustrating" that so basic feature is still not getting high prio enough...
could 2.2 forward attachment?
is this something we plan to be bring in next release?
I do hope so, current email client is seriously crippled without such basic feature and I personally miss it a lot. Sometimes I got email with not openable/downloadable content and since I'm also unable to forward it to someone else's email, frustration is very big...
From an email perspective, this is currently on the v2.2 shortlist, especially since supporting all attachment types (such as PDF) via the planned download manager UX is intimately coupled with fixing this bug.
Wilfred, it's under consideration. I'd like to do it for parity if possible. The rest of the email backlog (even with RTL support included) is short right now. Andrew, can you ping me (swilkes on IRC) and walk me through the co-dependent relationship this might have with download manager? :) Thanks!
It's already represented in this bug's unresolved dependency; bug 1017924. The download manager-integration bug is bug 825318 which (now) also depends on that bug.
This is in for 2.2.
[Tracking Requested - why for this release]:
Hi, Is there any chance to support this in 2.2? It is very important feature for most of our partners. Thanks, David
This is likely too risky for v2.2 given scope changes. However, if we implement bug 825318 (and make sure all pick/share filters are relaxed), it becomes possible for users to manually perform a workaround here by manually downloading the attachments and re-attaching them.
(In reply to Andrew Sutherland [:asuth] from comment #19) > This is likely too risky for v2.2 given scope changes. However, if we > implement bug 825318 (and make sure all pick/share filters are relaxed), it > becomes possible for users to manually perform a workaround here by manually > downloading the attachments and re-attaching them. Thanks Andrew. Thanks for the workaround, this is useful, but probably not very This is important IMHO, and it's being requested from 1.0 as a basic feature requested by users and partners. Are we sure that we cannot commit this for 2.2? Cheers, David
The fundamental tension is between v2.2 and v3.0. Most of the work that we would do on this for v2.2 would be effectively thrown away for v3.0 assuming we're adding conversation support. I'm also very concerned about the edge-cases for this that would be specific to the v2.2 and not shared by the v3.0 codebase, so we'd also be looking at a lot of potential QA-interaction and bugfixing overhead. A guesstimate would be that the cost would be 6-8 weeks of lost engineering effort from a v3.0 perspective. If product can commit that v2.2 will only ever be used on devices with always-present internal SD storage with size >1G and internal app storage with size >512M and we can force the email app to only use internal SD for this case (ignoring the user preference), then we can probably bring that lossage down a bit since that drastically reduces the set of edge-cases we need to deal with.
I dont think there is any way for this to be guranteed.