722929 - Update file attachments at send-time on drafts/templates (need a way to request "Don't read attachment file until when actually sending mail message")

Status: NEW

(MailNews Core :: Attachments, enhancement)

Description

[Troy Tamas]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

Send a templated email on a daily basis, with a specified attachment


Actual results:

Attachment file is saved to draft  (i.e. the version of the file that was created on day one), but subsequent updates are not reflected.


Expected results:

I would like either the "attachment" on the template to be a pointer to the file, so that the actual, updated file would be attached at send-time, or at least the option to update the attachment at send-time. Right now, I must find and reattach the file every time the email is sent. For a template email, I feel like this would be the standard UX expectation.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Just an idea for solution.
(1) Utilize X-Mozilla-External-Attachment-URL: which was implemented for Detach.
> Content-Type: message/rfc822; name="test.eml"
> Content-Disposition: attachment; filename="test.eml"
> X-Mozilla-External-Attachment-URL: file:///C:/wada/@@@/Folder/savedir1/test.eml
> X-Mozilla-Altered: AttachmentDetached; date="Thu Feb 02 12:12:42 2012"
(2) New function of "Attach file as template".
    Generates following header only.
> Content-Type: application/pdf; name="xxx.pdf"
> X-Mozilla-External-Attachment-URL: file:///C:/ ... /xxx.pdf
> X-Mozilla-Altered: AttachmentTemplate; date="Thu Feb 02 12:12:42 2012"
(3) Don't resolve External-Attachment-URL: upon Save As Draft, Save As Template.
    Resolve External-Attachment-URL: upon actual Send only(Send, Send Later)
(4) Attachment display in mail view.
    Almost same as current, with different icon from "Detached".
(5) Attachment display in mail composition.
    Almost same as current, with different icon from "Detached".

Some peoples want (A) attachment data of snapshot upon attach request, but other peoples want (B) attachment data of latest file upon mail send.
Because attachment file is currently read upon first Draft Save(if template, upon Save As Template), attached data is (A) if draft save occurs during mail composition, but attached data is (B) if draft save doesn't occur during mail composition. So, it is producing user's confusions.

Because your request is for template, it's absolutely irrelevant to (A) vs. (B) war :-) Above (3) is also a solution for request of (B) and also a solution of problem like "Draft save takes long if big attachment, especially when IMAP".

Issue in above solution.
If mail composition window is opened by "sendto/mail recipient" of MS Win, file is copied to ...\Temp\moz_mapi and file in the moz_mapi directory is passed as attachment file. If this mail is saved as template, attached file in template is different from original file. It's same as current, but it will produce new kind of user's confusion if "Attach file as template" like feature will be implemented.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to Troy Tamas from comment #0)
> For a template email, I feel like this would be the standard UX expectation.

I think so too. Change to New, because I believe reasonable request, although this bug is enhancement request and I'm merely an user, am not responsible on developement.

Comment 3

[Thomas D. (:thomas8)]

(In reply to WADA from comment #1)
> Just an idea for solution.

FTR, WADA's ideas here look very good to me.

> (1) Utilize X-Mozilla-External-Attachment-URL: which was implemented for
> Detach.
> (2) New function of "Attach file as template".

I agree with the idea, but I'm not sure if the *wording* gets the idea across correctly. "Attach file as template" still sounds as if the file will be attached immediately ("as template", the meaning of which imo is not clear), whereas we (per this RFE) just want to attach a link, and attach the real file later. So maybe "Attach file when sending" would be better? Or maybe I just need more time to get used to the intended meaning of "attach as template"...

>     Generates following header only.
> > Content-Type: application/pdf; name="xxx.pdf"
> > X-Mozilla-External-Attachment-URL: file:///C:/ ... /xxx.pdf
> > X-Mozilla-Altered: AttachmentTemplate; date="Thu Feb 02 12:12:42 2012"
> (3) Don't resolve External-Attachment-URL: upon Save As Draft, Save As
> Template.
>     Resolve External-Attachment-URL: upon actual Send only(Send, Send Later)
> (4) Attachment display in mail view.
>     Almost same as current, with different icon from "Detached".
> (5) Attachment display in mail composition.
>     Almost same as current, with different icon from "Detached".
> 
> Some peoples want (A) attachment data of snapshot upon attach request, but
> other peoples want (B) attachment data of latest file upon mail send.
> Because attachment file is currently read upon first Draft Save(if template,
> upon Save As Template), attached data is (A) if draft save occurs during
> mail composition, but attached data is (B) if draft save doesn't occur
> during mail composition. So, it is producing user's confusions.

That confusion, plus the additional confusion of "issue" below, is the main reason for bug 378046, but I think (at least for POP3 accounts), the technical details different (see bug 378046, comment 60):

* (POP3) Attachment file is currently *not* read as snapshot upon first save of draft (Ctrl+S), but only when draft message is *closed*, which of course requires prior saving.

STR to test this behaviour:
1) POP3 acct, compose, add file attachment
2 [review]) Ctrl+S to save draft (don't close the draft msg)
3) hover attached file in attachment pane (tooltip will show current file path, which is still linking to original location of file on user's file system)
WADA, on IMAP, TB will take the snapshot right now upon first saving of the draft?

4) close draft (save changes), then reopen
5) hover attached file again (tooltip will now show that TB has taken a static snapshot)

> Issue in above solution.
> If mail composition window is opened by "sendto/mail recipient" of MS Win,
> file is copied to ...\Temp\moz_mapi and file in the moz_mapi directory is
> passed as attachment file. If this mail is saved as template, attached file
> in template is different from original file. It's same as current, but it
> will produce new kind of user's confusion if "Attach file as template" like
> feature will be implemented.

That's bug 378046. For details, see bug 378046, comment 60.
Practically, WADA is supporting the bottom line of bug 378046:
- Current behaviour is confusing and inconsistent as it varies depending on the *method* of attaching (mapi vs. non-mapi), and depending on *saved/closed-status* of draft
- Current behaviour needs to be made consistent and predictable:
- As a minimal solution, always take snapshot immediately upon attaching (A) (for reasons why (B) alone cannot be the minimal solution, see bug 378046, comment 60, 4a)-d); btw, e): all web mailers necessarily have (A) as their default behaviour, so that's where user expectations are set)
- As an extra RFE (this bug), allow alternative method of "attach when sending", i.e. take snapshot upon sending (B)

The good news is that with WADA's detailed concept of comment 1, (B) seems relatively easy to do with existing code. But before implementing (B), we need bug 378046 first, which requires a cleanup of backend code to make the behaviour consistent.

Comment 4

[Thomas D. (:thomas8)]

tweaking summary for better retrievability, e.g. to match "when sending message"

Comment 6

[Thomas D. (:thomas8)]

In bug 521158, we've just landed significant enhancements of attachment reminder functionality. Independent of already attached files, users can now activate "Remind me later" at any time during composition. They will then definitely get the "Attachment Reminder" alert upon sending.

That feature [bug 521158] will be highly beneficial for all those users who want to add the most recent version of their attachments just before sending [this bug 722929]. The workaround is almost as good as the feature, only that you can't specify a file name in advance.