Closed Bug 36492 Opened 20 years ago Closed 16 years ago

Optional separate Recipient and Sender columns in thread pane

Categories

(SeaMonkey :: MailNews: Message Display, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.6alpha

People

(Reporter: BenB, Assigned: emaijala+moz)

References

Details

Attachments

(1 file, 2 obsolete files)

Assuming, we will have configurable columns, I suggest to offer the combined
To/From field* (default) and additionally separate Recipient and From fields.
The user would then be able to choose any combination of them using the generic
column configuration methods.

Relevance: The logic of the combined column might fail in some advanced cases.

*the current and 4.x behaviour or the "intelligent" combined column proposed in
bug 36489.
> Assuming, we will have configurable columns

Em, well, we already have...
Looking for help implementing this one.
Assignee: selmer → nobody
Keywords: helpwanted
Target Milestone: --- → M30
*** Bug 66431 has been marked as a duplicate of this bug. ***
QA Contact: lchiang → nbaca
*** Bug 75429 has been marked as a duplicate of this bug. ***
The ability to change the order of the columns would be worth it, too.

My $0.02 ...

If you'd like to nominate this for 0.9 add it to the whiteboard... worst case,
it gets bumped back down...
I agree that separate To and From fields would be a very good idea.  Is this a
trivial task?
Bugs 21586 61651 and 72791 would be fixed with this addition
Currently the Trash folder and custom folders offer the column 'Sender', but
unfortunately the field 'Recipient' is missing in the drop down list and in
advanced search.
Does this bug mean that currently these two fields are mutually exclusive?
Robert, this is exactly what this bug is about.

> Bugs 21586 61651 and 72791 would be fixed with this addition

Bug 21586 might be a dup, the others are fixed already.
QA Contact: nbaca → olgam
*** Bug 111617 has been marked as a duplicate of this bug. ***
reassigning to sspitzer.
Assignee: nobody → sspitzer
Target Milestone: --- → mozilla1.2
*** Bug 118417 has been marked as a duplicate of this bug. ***
Dupe Bug #118417 has a partial patch to implement this as an attachment.
surely this bug and bug 36489 are essential for a 1.0 release - its literally
the only reason I'm not using moz mail/news at the moment since i cant see the
To: field in the message list which is useful for seeing the recipient name of a
unix alias mail list. (described well in Bug 118417) Also, you're going to need
this to convince OutLook Express users to migrate.
Surely it should be a relatively easy patch to add the To: column in the view.
Even if the combined Recipient/From field patch cant be done, cant we include
something like the patch in Bug 118417 for the 1.0 release ?
see also bug 107073
Summary: Optional separate Recipient and From columns in thread pane → Optional separate Recipient and Sender columns in thread pane
*** Bug 107073 has been marked as a duplicate of this bug. ***
*** Bug 176381 has been marked as a duplicate of this bug. ***
*** Bug 171512 has been marked as a duplicate of this bug. ***
*** Bug 182912 has been marked as a duplicate of this bug. ***
Are there any chances to get separate Recipient and Sender columns
in Mozilla release 1.3? This would be great.
*** Bug 187226 has been marked as a duplicate of this bug. ***
*** Bug 134446 has been marked as a duplicate of this bug. ***
*** Bug 190269 has been marked as a duplicate of this bug. ***
*** Bug 191458 has been marked as a duplicate of this bug. ***
*** Bug 191958 has been marked as a duplicate of this bug. ***
There are (parts of) patches to fix this. I tried it too. But the problem is:
where to put the 'optional'? In the column picker would be the most obvious. But
that lead to the following options: Sender, Reciepient, Recipient (when you are
in the sent-folder). The second recipient is form what we have now, and wil turn
into Sender for other folders. This would be confusing. 
Another option would be to put it in preferences. Then we can remove the
automatic changing column. But that would give two paces to set which columns to
see.
Anyone has a better idea?
Cal the automatically switching Recipient/Sender column slightly different, but
in a way that makes the idea clear (also consider bug 36489), and rely on the
user's intelligence to remove the automatically switching column after he added
the individual columns.
Well, I hope so!  Please make it so simple.  Just add "Recipient" in the choices
which drop down for which columns to include.  Leave "Sender" in the list as
usual.  Please DO NOT make anything depend on whether the mail folder has some
magical name like "Sent"!  The simple and easy-to-understand thing is just to
let the user pick which columns get displayed, with total disregard as to the
name of the folder.  If I'm documenting a project, I want to pile all the emails
that pertain to that project into one folder, and show both Sender and Recipient. 
I agree with #27
I also agree with #27.  Please keep it simple.
Piling on.  I keep an archive of every email that I've ever sent, and I
periodically move items from my sent folder into this archive so that I don't
have to look through thousands of emails if I'm looking for something recent. 
The problem now is that I can't sort the emails in the archive by recipient if I
want to find a message that I sent to a specific individual.  I'm not sure why I
can't select any column in any folder.
The Problem in #30 is mine, too
I just found out that you can give the entries in the column picker an other
label then the columns. So that can be something like 'Sender (auto)'
That leaves the View>Sort menu as a problem.

Seth Spitzer, what do you think of this? The most easy way to fix this would be
to drop the automatic column selection. I have been looking at the code, and I
needed a few ugly hacks to make it work. And it is not even finished.

Oh, we already know that there are people that want this fixed (including me).
Spamming the bug with that is useless.
I also agree with 27. I want to be able to display BOTH the sender and recipient
for EVERY file of email if I wish. 
Judging from comments in bug 36489, Netscape wants to keep the current auto
column the default, and I think that's a reasonable choice. So, any columns
added here would be opt-in, disabled by default, as the summary and initial
descritpion states.

I don't think that any hacks are needed for this bug. It should be fairly easy
to implement. Maybe you can cheat at the code in bug 36489 (which is harder).
Attached patch Proof-of-concept patch (obsolete) — Splinter Review
This is a proof-of-concept. I don't guarantee that it is complete.

It add two columns, sender and recipient. The ugly part of the patch is the
working around the existing colum, which sometimes is sender, and sometimes
recipient. In the column picked and in the View>Sort By menu, I renamed it to
"Recipient (auto)" or "Sender (Auto)". Anybody has a better wording suggestion?
#27 is right. Let the all authomatism still in operation of adding new folder -
if it "sent" - then by default let there be "recepient", all other cases -
"sender". That's all. If the men move folder to any place - this setting not
change automaticaly. Owner can switch this property, or add other field
(according, sender or recepient) manualy.
I'm going to take a look.
For what it's worth, perhaps I can offer a situation where the "auto"
functionality is indeed causing a problem.  I believe it's been affecting me
since the beginning, all the way up to the Mozilla 1.3beta which I'm using now.

I have two imap accounts set up in my Mozilla mail reader:

The first account connects to a Linux imap server.  *All* of the folders and
subfolders (including the "Sent" folder) have the "Sender" column, and no
"Recipient" column is available.  This is as expected from what I'm reading
here, aside from the "Sent" folder which I assume should've been the opposite.

The second account connects to a Microsoft Exchange server.  *All* of the
folders and subfolders here *only* include the "Recipient" column, and no
"Sender" column is available.

Perhaps the weirdness experienced in the second account can be attributed to the
"auto" column type functionality?
*** Bug 191345 has been marked as a duplicate of this bug. ***
Some related bugs:

Bug 123707 - All columns should be available in all folder types
Bug 114533 - "Sender" column lists recipient when INBOX is set as the "Sent" folder
I agree with many of you above! I store all of my emails (send and recieved) in
the same folder structure (user-created folders, treated as Inboxes, where only
the sender is shown). So I have to open every single email send by me to find
the one with a specific recipient! 

Please make it possible to get a Sender- AND a Recipient-columns for each
folder! I'd like to do it myself, but have no experience with coding, sorry :-)
I also think the "Recipient"-column in every folder is neccessary. Not only if
you store your sent mail in some other folder than sent. If you get mail from
different accounts forwared to one account or if the mail was sent as a CC or to
a mailinglist, you want to see to wich recipient it was addressed. 
This is a case where an intended 'feature' turns out as a (long standing, since
first NS MailNews release), important usage bug; developers insists on striving
to find the best possible algorithm|logic to automate what users are really
unbeatable to do (and unpredictable) - making choices in a fuzzy context - while
  keeping out of mainstream code that would let users make their choice the
plain way. 

 And here's 1.4b that still decides on its own which headers are proper for
which folder... doing the wrong thing of course. So many still need to stick to
e.g. StarOffice's mailnews to keep seeing what they need to see and sort.

I'd suggest that (and would like to have), the only 'automation' be actually a
'courtesy', i.e. 'usually inbound' folders pre-set at least 'From:' header on,
'usually outbound' folders pre-set at least 'To:' header on; and have all
possible headers+fields line up in the headers pop-up menu, regardless of folder
name|function; let the user decide, there are just too many cases out there (or
here) to make the default right choice for everyone.

Should anybody come up with a nice neuro-fuzzy classifier+sorter (e.g. derived
from anti-spam code), pls add a proper preference leaf, so that 'engine' can be
(de)activated at user's will.
uh, just pls don't add blathering clips though ...

Reg. names... again why not keep it plain+simple: don't combine, and stick to
RFC names almost every (email)user is used to: From: Subject: To: Cc: Bcc:
Sender: reply-to: ... that would be an easier common base for 'localisers' as well.
*** Bug 208141 has been marked as a duplicate of this bug. ***
*** Bug 212378 has been marked as a duplicate of this bug. ***
*** Bug 216097 has been marked as a duplicate of this bug. ***
*** Bug 217712 has been marked as a duplicate of this bug. ***
*** Bug 218275 has been marked as a duplicate of this bug. ***
*** Bug 219023 has been marked as a duplicate of this bug. ***
as we can see, the demand for this feature is quite high. could someone please 
say something about the status of implementation of this feature? is there 
anybody working on it?
Taking, I'll give it a shot.
Assignee: sspitzer → ere
Status: NEW → ASSIGNED
Keywords: helpwanted
Attached patch v1 Patch (obsolete) — Splinter Review
Ok, here is my first try for a solution: two separate columns that are switched
according to the folder type. The default behavior is almost same as before,
but the columns can be shown and hidden separately for both folder types. Also
sort menu has been changed to include both columns.
Comment on attachment 131411 [details] [diff] [review]
v1 Patch

Neil, could you review the xul part of this patch?
Attachment #131411 - Flags: review?(neil.parkwaycc.co.uk)
David, could you review the non-xul part of the patch?
Comment on attachment 131411 [details] [diff] [review]
v1 Patch

Talked with Neil in IRC, improvements coming up soon.
Attachment #131411 - Attachment is obsolete: true
Attachment #131411 - Flags: review?(neil.parkwaycc.co.uk)
Attached patch v2 PatchSplinter Review
Second patch with a new, more beautiful approach (thanks Neil) to the column
handling in xul. Also removes the unnecessary
nsMsgThreadsWithUnreadDBView::Open() and some unused items from
messenger.properties.
Attachment #113713 - Attachment is obsolete: true
Comment on attachment 131414 [details] [diff] [review]
v2 Patch

Again requesting review of the XUL part from Neil and others from Bienvenu.
Attachment #131414 - Flags: review?(neil.parkwaycc.co.uk)
Target Milestone: mozilla1.2alpha → mozilla1.6alpha
Comment on attachment 131414 [details] [diff] [review]
v2 Patch

sr=bienvenu
Attachment #131414 - Flags: superreview+
Comment on attachment 131414 [details] [diff] [review]
v2 Patch

Could you remove the ^Ms in mailContextMenus too :-)
Attachment #131414 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 131414 [details] [diff] [review]
v2 Patch

Requesting review for the non-xul part of the patch.
Attachment #131414 - Flags: review+ → review?(scott)
Neil: I'll check the fixed mailContextMenus in too with the others.
Comment on attachment 131414 [details] [diff] [review]
v2 Patch

Ok, Neil's r with Bienvenu's sr ought to be enough.
Attachment #131414 - Flags: review?(scott) → review+
Patch checked in. Let me know of any regressions.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
There is kinda regression related to your patch.

I build thunderbird (on a CVS updated trunk source), and message display is blocked.

I am having the waiting icon and nothing more in display frame :(

I will see if the bug is also present in mozilla mailnews as soon as possible.
It seems to be a thunderbird only bug :(

No regression in a fresh (2 minutes old) CVS based trunk mozilla build.
I thought Thunderbird uses the same chrome files, but obviously it has some
differences that need to be addressed. I haven't done any TB stuff, but please
file a bug about it and at least cc me.
People who voted for this bug might want to move their votes over to bug 76702, 
which is now even more desirable because of this new feature.
Or they may just say thanks to ere for implementing this and being happy about
the great new feature.
You are right. This new feature will be very useful, for example, to manage sent
mails filed in folders by subject (without "Recipient" column until now). Thank
you very much. :-)
Frederic, have you filed a bug for the thunderbird problem?
I couldn't find one.
I can reproduce this problem on thunderbird too
work is in progress for thunderbird, see bug 218275
in answer to comment #70 : don't filed one.

I will build 0.3a thunderbird until bug is fixed :)

in answer to comment #71 : I am CC myself :-)
v
Status: RESOLVED → VERIFIED
This has caused bug 220727.
*** Bug 214578 has been marked as a duplicate of this bug. ***
*** Bug 236672 has been marked as a duplicate of this bug. ***
*** Bug 62599 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 232090 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 21586
(In reply to Ben Bucksch (:BenB) from comment #0)
> [With] configurable columns, I suggest to offer the combined
> To/From field* (default) and additionally separate Recipient and From fields.
> The user would then be able to choose any combination of them using the
> generic column configuration methods.

Following Ben's philosophy of empowering users with customizable choices according to their own preferences and needs, Bug 699588 seeks to implement optional columns for CC and BCC headers, in addition to the existing To column currently labeled "Recipients" (Bug 522885). Bug 522886 adds further value by making "Recipients" column actually show *all* recipients regardless of their flavor (To, CC, and BCC).
You need to log in before you can comment on or make changes to this bug.