169025 - View any mail folder as sent-mail

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Everett Stauffer]

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.

Comment 1

[Mike Cowperthwaite]

Everett, depending on how you envision this being done, this bug is a dupe of 
bug 36492 or bug 36489; which do you prefer?

Comment 2

[Everett Stauffer]

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!

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[Everett Stauffer]

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.

Comment 5

[Joe Infla]

*** Bug 219023 has been marked as a duplicate of this bug. ***

Comment 6

[Stefan Borggraefe]

Confirming. It makes sense to make it freely configurable for every folder
whether it shows the Receiver or the Sender.

Comment 7

[Peter Mørch]

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.

Comment 8

[Mike Cowperthwaite]

*** Bug 224655 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

Peter Mørch, I agree with your concerns; those should be raised in bug 76702.

Comment 10

[Robert Kaiser]

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

Comment 11

[Robert Kaiser]

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