For users with a large amount of sent mail, breaking up the folders is a performance necessity. Abusing the current settings can give the user a maximum of two folders treated as sent-mail. (Sent for email and news.) Enhancement could go into either/both the right-click menu or in the top- level View menu. Entry would read "View as Sent Mail". Enhancement would allow any folder to be viewed as "sent mail", showing recipient field, rather than sender field.
Hi Mike- Having a bit of trouble trying to understand the difference between the other two bugs since they both seem to suggest that the Sender and Recipient fields would be 'selectable'. As such, that method is certainly acceptable. The caveat would be that the "view" would need to 'stick' to the folder. e.g. If I set up my view to show Recipient on sent-mail-03aug, then when I come back to that folder, I don't have to re-setup the view. Thank you!
The difference is, bug 36492 specifies two different possible columns -- one always Sender, the other always Recipient; bug 36489 specifies one column which intelligently determines whether to show the Sender or Recipient for a given message (presumably shows Recipient unless Recipient). As for sticky column views -- from what I've seen, there is currently only one set of columns stored. I would think that also needs to be fixed; it would be nice to have it on a per-folder basis, if not per-account. See bug 76702 and bug 148901.
Gotcha! Great explanation, Mike. As far as the columns and settings go: Just like other columns in the view, there should, by default, be both the sender and recipient columns. The user should be able to select/deselect the view of those columns just like any other currently available column. If this was applied on a per-folder basis it would solve so many (of our) user scenarios as to make this particular RFE "closed" (along with the other 4 bugs.) On the other hand, given the behavior that we have witnessed, it seemed like a straightforward addition to the current code. For instance, a file marked as sentmail can be made to continue to 'act' that way after another file is marked IF you protect the .msf file. If the .msf is removed and new one created by the program, the new .msf will show the sender view instead of the desired recipient view. My theory is that the .msf files contain a flag of some sort that determines the sender/recipient view. This RFE was submitted on the basic concept of just putting an interface on a call to set the flag in the .msf for the file.
*** Bug 219023 has been marked as a duplicate of this bug. ***
Confirming. It makes sense to make it freely configurable for every folder whether it shows the Receiver or the Sender.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [RFE] View any mail folder as sent-mail → View any mail folder as sent-mail
I would like to warn against making column selection a pr. folder thing. Instead I suggest making "View as Draft/Sent Mail" a property for each folder instead, defaulting to unchecked for all folders except Sent and Draft (and their subfolders as reported in bug #93863) The problem with pr. folder column selections is: What happens when the user later decides to add the "Size" field? Or decides to resize the Subject field? Then we'll quickly end up with each folder having their columns (and their width's) configured differently. Not a desirable situation in my opinion, as it will be annoying to have to keep all the folders up-to-date by hand. Global column configuration is still the way to go in my opinion.
*** Bug 224655 has been marked as a duplicate of this bug. ***
Peter Mørch, I agree with your concerns; those should be raised in bug 76702.
Assignee: mail → nobody
QA Contact: laurel → message-display
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.