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)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.6alpha
People
(Reporter: BenB, Assigned: emaijala+moz)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
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.
Reporter | ||
Comment 1•25 years ago
|
||
> Assuming, we will have configurable columns
Em, well, we already have...
Comment 2•25 years ago
|
||
Looking for help implementing this one.
Updated•24 years ago
|
QA Contact: lchiang → nbaca
Comment 5•24 years ago
|
||
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...
Comment 6•24 years ago
|
||
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
Comment 7•23 years ago
|
||
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?
Reporter | ||
Comment 8•23 years ago
|
||
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.
Updated•23 years ago
|
QA Contact: nbaca → olgam
*** Bug 111617 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
reassigning to sspitzer.
Assignee: nobody → sspitzer
Target Milestone: --- → mozilla1.2
Comment 11•23 years ago
|
||
*** Bug 118417 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
Dupe Bug #118417 has a partial patch to implement this as an attachment.
Comment 13•23 years ago
|
||
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 ?
Comment 14•22 years ago
|
||
see also bug 107073
Updated•22 years ago
|
Summary: Optional separate Recipient and From columns in thread pane → Optional separate Recipient and Sender columns in thread pane
Comment 15•22 years ago
|
||
*** Bug 107073 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
*** Bug 176381 has been marked as a duplicate of this bug. ***
Comment 17•22 years ago
|
||
*** Bug 171512 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 182912 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
Are there any chances to get separate Recipient and Sender columns
in Mozilla release 1.3? This would be great.
Comment 20•22 years ago
|
||
*** Bug 187226 has been marked as a duplicate of this bug. ***
Comment 21•22 years ago
|
||
*** Bug 134446 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 190269 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
*** Bug 191458 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
*** Bug 191958 has been marked as a duplicate of this bug. ***
Comment 25•22 years ago
|
||
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?
Reporter | ||
Comment 26•22 years ago
|
||
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.
Comment 27•22 years ago
|
||
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.
Comment 28•22 years ago
|
||
I agree with #27
Comment 29•22 years ago
|
||
I also agree with #27. Please keep it simple.
Comment 30•22 years ago
|
||
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.
Comment 31•22 years ago
|
||
The Problem in #30 is mine, too
Comment 32•22 years ago
|
||
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.
Comment 33•22 years ago
|
||
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.
Reporter | ||
Comment 34•22 years ago
|
||
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).
Comment 35•22 years ago
|
||
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?
Comment 36•22 years ago
|
||
#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.
Assignee | ||
Comment 37•22 years ago
|
||
I'm going to take a look.
Comment 38•22 years ago
|
||
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?
Comment 39•22 years ago
|
||
*** Bug 191345 has been marked as a duplicate of this bug. ***
Comment 40•22 years ago
|
||
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
Comment 41•22 years ago
|
||
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 :-)
Comment 42•22 years ago
|
||
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.
Comment 43•22 years ago
|
||
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.
Comment 44•21 years ago
|
||
*** Bug 208141 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
*** Bug 212378 has been marked as a duplicate of this bug. ***
Comment 46•21 years ago
|
||
*** Bug 216097 has been marked as a duplicate of this bug. ***
Comment 47•21 years ago
|
||
*** Bug 217712 has been marked as a duplicate of this bug. ***
Comment 48•21 years ago
|
||
*** Bug 218275 has been marked as a duplicate of this bug. ***
Comment 49•21 years ago
|
||
*** Bug 219023 has been marked as a duplicate of this bug. ***
Comment 50•21 years ago
|
||
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?
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•21 years ago
|
Keywords: helpwanted
Assignee | ||
Comment 52•21 years ago
|
||
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.
Assignee | ||
Comment 53•21 years ago
|
||
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)
Assignee | ||
Comment 54•21 years ago
|
||
David, could you review the non-xul part of the patch?
Assignee | ||
Comment 55•21 years ago
|
||
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)
Assignee | ||
Comment 56•21 years ago
|
||
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
Assignee | ||
Comment 57•21 years ago
|
||
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)
Assignee | ||
Updated•21 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.6alpha
Comment 58•21 years ago
|
||
Comment on attachment 131414 [details] [diff] [review]
v2 Patch
sr=bienvenu
Attachment #131414 -
Flags: superreview+
Comment 59•21 years ago
|
||
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+
Assignee | ||
Comment 60•21 years ago
|
||
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)
Assignee | ||
Comment 61•21 years ago
|
||
Neil: I'll check the fixed mailContextMenus in too with the others.
Assignee | ||
Comment 62•21 years ago
|
||
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+
Assignee | ||
Comment 63•21 years ago
|
||
Patch checked in. Let me know of any regressions.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 64•21 years ago
|
||
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.
Comment 65•21 years ago
|
||
It seems to be a thunderbird only bug :(
No regression in a fresh (2 minutes old) CVS based trunk mozilla build.
Assignee | ||
Comment 66•21 years ago
|
||
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.
Comment 67•21 years ago
|
||
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.
Reporter | ||
Comment 68•21 years ago
|
||
Or they may just say thanks to ere for implementing this and being happy about
the great new feature.
Comment 69•21 years ago
|
||
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. :-)
Comment 70•21 years ago
|
||
Frederic, have you filed a bug for the thunderbird problem?
I couldn't find one.
I can reproduce this problem on thunderbird too
Comment 71•21 years ago
|
||
work is in progress for thunderbird, see bug 218275
Comment 72•21 years ago
|
||
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 :-)
Comment 74•21 years ago
|
||
This has caused bug 220727.
Comment 75•21 years ago
|
||
*** Bug 214578 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
*** Bug 236672 has been marked as a duplicate of this bug. ***
Comment 77•20 years ago
|
||
*** Bug 62599 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 78•19 years ago
|
||
*** Bug 232090 has been marked as a duplicate of this bug. ***
Comment 80•11 years ago
|
||
(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.
Description
•