Closed Bug 36492 Opened 25 years ago Closed 21 years ago

Optional separate Recipient and Sender columns in thread pane

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: BenB, Assigned: emaijala+moz)

References

Details

Attachments

(1 file, 2 obsolete files)

v2 Patch
29.04 KB, patch
emaijala+moz
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
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 Patch — — Splinter 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: 21 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. ***
(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.

Attachment

General

Creator:
Created:
Updated:
Size: