912002 - [email][User Story] Productivity25: Support forwarding attachments

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, enhancement)

Description

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

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.

Comment 2

[lecky]

Hi Wayne :
 Could you tell me that this new feature will be supported on V1.2 or more new SW?

Comment 3

[Wayne Chang [:wchang]]

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.

Comment 6

[Noemí Freire (:noemi)]

It has been reported by TEF BUs during v1.3 IOT process so adding to backlog to be properly prioritized. Thanks!

Comment 7

[Juwei Huang[:juwei]]

Attachment: [Email] Forward & reply message_20140707.pdf

Spec attached.

Comment 8

[Kai-Chih Hu [:khu]]

Use feature-b2g:2.2? rather than just 2.2.

Comment 9

[Marek Raida]

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...

Comment 10

[Nancy]

could 2.2 forward attachment?

Comment 11

[Wilfred Mathanaraj [:WDM]]

is this something we plan to be bring in next release?

Comment 12

[Marek Raida]

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...

Comment 13

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

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.

Comment 14

[Stephany Wilkes]

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!

Comment 15

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

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.

Comment 16

[Stephany Wilkes]

This is in for 2.2.

Comment 17

[Jacob Shen]

[Tracking Requested - why for this release]:

Comment 18

[David Palomino [:dpalomino]]

Hi, 

Is there any chance to support this in 2.2? It is very important feature for most of our partners. 

Thanks, 
David

Comment 19

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

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.

Comment 20

[David Palomino [:dpalomino]]

(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

Comment 21

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

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.

Comment 22

[Wilfred Mathanaraj [:WDM]]

I dont think there is any way for this to be guranteed.

Comment 24

[BMO Automation]

Firefox OS is not being worked on