Closed Bug 123707 Opened 20 years ago Closed 12 years ago
All columns should be available in all folder types
Currently user defined mail folders only reflect attributes of an 'Inbox'. I would like the ability to modify a user defined folder to reflect attributes of a 'Sent' folder so that I can veiw Sender IDs in the summary view and run searches based on Sender ID, etc.
you want a new ui view, which means it's a front end rfe. And you can search for sender in any folder you want, by using the search ui.
Component: Mail Database → Mail Window Front End
Summary: Request for ability to change mail folder attributes → RFE Request for ability to change mail folder attributes
Target Milestone: --- → Future
Sorry, I meant ability to search for recipient ID, not sender ID.
right, you can do that too, from the search ui, just not from "Quick Search". Search | Search Messages. I realize it's not as convenient as Quick Search, but I just want to make sure you're aware of it.
I think this is what reporter wanted in bug 121700
If I understand you correctly, the end result should be something like this: * All folders should have the same set of attributes, and they should all be available as columns, thus getting you a sender column in draft,sendt etc, and a recipient column in Inbox. * this way user defined folders all get all the attributes/columns and not be tied to a certain type. * All coloums/attributes should be usable in search/quicksearch etc. Reporter is this what you meant ?
Yes, that is exactly what I am referring to. The problem manifests itself when I attempt to archive messages in the 'sent' folder. Messages in the 'sent' folder are searchable by 'recipient'. When I create an archive folder for a selected period, say a given year, and move my accumulated 'sent' messages to that folder, I am no longer able to search by 'recipient' and in place of the 'recipient' field I get 'sender' which of course is meaningless, because it is always me. 'Sent' and 'Drafts' obviously share the same attributes which are different from 'Inbox' and all the other mail folders including user generated folders. Thus when I move a sent message to a user generated folder, it gets treated as a received message. I would like either the ability to toggle the attributes of a user generated folder between outgoing and incoming, or the ability to display all fields in the summary list for a user generated folder. I know I'm rambling here, I hope I am making myself clear. Thanks for listening! Mozilla is absolutely the best browser/email client around, and it is getting better all the time. You are all doing a great job!!! Thanks!
confirming bug, and changeing subject to reflact the more generelized view
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: RFE Request for ability to change mail folder attributes → All coloumns should be available in all folder types
Target Milestone: Future → ---
I'm having the same problem but with IMAP (courier IMAP); I've created Sent, Drafts etc... folders and configured the mailsettings to use those folders in stead of the local ones. Mozilla doesn't recognize treats them as normal folders except for Trash (Trash has got a Trash icon, all the others have a normal folder icon). As my IMAP-Sent folder is a normal (Inbox) folder, I cannot add a Recipient view. Adding Sender/Recipient views to all folders would be a nice solution. Is it possible to give the Mail-folders (Sent, Drafts etc...) their proper icon like with the local folders?
I was going to report this as a bug today. But let me add to this bug with information specific to my situation. I also use a Courier IMAP server running on FreeBSD. But all of my Mozilla 1.2.1 and 1.3a clients run on Windows 2000. This seems to be a more critical issue, so I would like it to become a normal bug. If the owner reads this, please upgrade the bug to include Windows and increase its priority. The issue may be only showing up for certain IMAP servers, but in general, it would be a nice thing to have the ability to change a folder's properties. If I was to right-click (Windows) on a folder, it gives me a properties option. Under the general tab, I would expect a way to force it to become a "SENT" folder, caps or no caps. I want it to behave like a sent or drafts folder. Bug 114533 seems to be similar (but the inverse) of this one -- he is having Inbox problems. Bug 174670 and bug 166603 also are related to this. I guess I need to add some of this info to these other bugs I mentioned. The full description of my problem is that when a user sends mail, the mail shows up in a subfolder of Inbox called "Sent." Great! What's not-so-great is that the Sent folder is full of messages that list the exact same SENDER. What we need is to list the individual RECIPIENT for each message, as any good Sent mail folder should. (The same issue is present in the Drafts subfolder.) The possible changes to Mozilla would be to allow a user to change the properties of a folder to make it "sent-like", or to actually have an option in any folder to show the RECIPIENT header. This would help in other issues, such as when the Trash folder gets full of my old sent messages.
A related bug is the following: Bug 36492 - Optional separate Recipient and Sender columns in thread pane
Can we confirm whether "Sender" and "Recipient" are the only two columns that this affects? If so then this can be more closely tied into bug 36492 which is close to being fixed...
can we confirm that the courier problems aren't fixed in 1.5 final or 1.6? bug 36492 is fixed in 1.6 now as well.
This bug was probably fixed at the same time as Bug 36492. I recommend closing this bug. WFM in Mozilla 1.7, Windows 2000, using Courier-IMAP server (see comment 9 -- me). I don't know when bug 36492 was fixed or verified, but it may have been in Mozilla 1.7. See also Bug 174670. The main issue I could still pick out is that when I try to change the column headers, there is a finite list of headers to choose from (I can't choose a header named "X-Spam-Status" or "MIME-Version" or "X-Mailer"! And as the people following Bug 40934 would know, one of the headers to choose from in the drop-down list is *not* the English word "From." (The word chosen was "Sender," which is a relatively rare name for an SMTP header!) In any case, this bug is not about the choice of the word "Sender" when the proper word for the header is "From," and so this one should be resolved.
Could we also spell the word "coloumns" as "columns" in the bug description? "All columns should be available in all folder types" might get more search hits.
coloumns --> columns Done.
Summary: All coloumns should be available in all folder types → All columns should be available in all folder types
Assignee: bienvenu → nobody
QA Contact: esther → 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
Closed: 12 years ago
Resolution: --- → EXPIRED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.