Closed Bug 169171 Opened 22 years ago Closed 18 years ago

Saving a composition does not save email priority setting

Categories

(MailNews Core :: Composition, defect)

x86
Windows 98
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 146075

People

(Reporter: silly, Assigned: bugzilla)

References

Details

(Keywords: dataloss)

When composing an email and you click 'Save' the priority setting of the email
is not saved.  When you bring the message back up from your draft box the
priority reverts back to normal.  Return Receipt settings are saved but not
priority.
This is still true, as tested in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516

Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: MailNews → Core
*** Bug 209036 has been marked as a duplicate of this bug. ***
bug 240675 deals with this same issue.

This bug is simple to reproduce.

In fact none of the "Options" are saved. Not when saved as a "Draft" or as a
"Template".  

Reproducible: Always
Steps to Reproduce:
1) Open a new e-mail message.  
   Enter an e-mail address, subject, and some text in the body.  

2) Then check any of the menu Items under "Options"
   Return Reciept
   Format
   Priority

3) Save the e-mail as a template or draft.

4) Close the e-mail compose window.

5) Open the template or draft message.  
6) Now check the Return Reciept, Format, and/or Priority Options.
   All of these value are the default values.  Nothing was saved.

Actual Results:  
The status of the Options (Return Reciept, Format, and Priority) were lost.

Expected Results:  
The status of the Options should have been saved.
Here's a little more info on this bug:

Yes this bug is still reproducable.

The priority flag is saved properly, but it is not read back in when you open
the template/draft.

Here is a snip from the template file in my mail folder

X-Priority: 1 (Highest)
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=1; uuencode=0

As you can see the priority flag is 1 but when I open the template the priority
menu item is not checked.  Moreover, when the message is sent, the priority flag
is set back to normal.

I know this is not a "critical" bug, but how many other options and settings are
not being read back in when opening a template/draft?

HINT: There are many!
proirity
format
encoding
return receipt
security(encrypt)

None of these are read back in from template/draft file.

Here's the problem.  I compose an email then set the security to encrypt the
message.  I get busy, save the email as a draft.  When I finaly get back to my
email, I oepn the draft, read it over and send.  OOOOPS! I just sent then email
unencrpted because my email client didn't set the proper flags.

This bug should be elevated to a security risk.

I know this bug is old, very old, but may I must ask this question.

Why it called a template if it does not store settings such as:
format, security, priority, and return receipt?

Call it a To:Subject:Body saver.  Or a "You must still click all the options and settings but we'll save the to field for you" widget.  But don't call it a "Template", that's misleading.

You know what the most annoying part about this bug is?  All the information above is save to the template file but not read back in when the template is opened.

Ok.  I'm done with my rant.
Based on comment 4, the Priority part is actually bug 146075.
Depends on: 146075
duping to bug 146075.
I think bug 83412 covers the other issues raised.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
No longer blocks: 216479
No longer depends on: 146075
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.