Closed Bug 359545 Opened 18 years ago Closed 15 years ago

using "place replies in the folder of the message replied to" checkbox prevents "place a copy in:" from working

Categories

(SeaMonkey :: MailNews: Account Configuration, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060907 SeaMonkey/1.1b Mnenhy/0.7.4.10002 Build Identifier: Using "place replies in the folder of the message replied to" in the Copies&Folders panel of a mail account makes Mailnews ignore the other location to place a copy of a sent message in. (see attachment: Despite both checkboxes being checked, only one copy of the message is placed in the folder of the message replied to, no copy is placed in "sent".) Reproducible: Always Expected Results: Place a copy of the message sent in both the folder of the message replied to and the "sent" folder (or the respective other folder set beyond the first checkbox)
see bug 301084 comment 10. So the backend is apparently working as designed. So the pref window should probably look a bit different. I'd expect something like having a radio button with the previous two instead of a checkbox. but it sounds like mscott specifically rejected that in favor of the current behavior (comment 49), so I'm a bit confused.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
(In reply to comment #2) If I understand mscott right, the second checkbox is supposed to be independent from the setting for a "sent" folder, because it should only affect replies. What I don't get is why using this option overrides the "sent" folder settings instead of supplementing them. Also, bug 359514 makes using this option rather confusing. In my opinion, the current behaviour and/or UI are wrong. The current UI suggests there will be *two* copies of a message reply: One in "sent", one in the folder the message replied to is in. There is *no* indication that using the checkbox *below* the one for the "sent" folder setting will deactivate it. So if this is the intended behaviour, the UI should be fixed to reflect that (e.g. by making the setting a third radio button) - if the UI is right, then the behaviour is wrong. Either way - we need a fix :-)
You still need somewhere to place copies of new messages. However, maybe it could be worded like this: [X] Save a copy of sent messages [ ] Place replies in the folder of the message being replied to Otherwise, file the copy in (*) "Sent" Folder on: [Local Folders |v] (*) Other: [Sent on Local Folders |v]
(In reply to comment #4) I still don't understand why there has to be a checkbox if the choice is an exclusive one. Making exclusive choices is what radio buttons are for after all. Is there a reason not to make it like this? [X] Save a copy of sent messages (*) Place replies in the folder of the message being replied to (*) "Sent" Folder on: [Local Folders |v] (*) Other: [Sent on Local Folders |v]
(In reply to comment #5) >Is there a reason not to make it like this? As I said in comment 4, you need to be able to specify where to put copies of messages that weren't replies.
(In reply to comment #6) Ooh, right - I misunderstood you, sorry. I can see the problem now. What about decoupling those settings? (see bug 359514 - sort of) With the current indentation, this is suggested anyway. This of course would mean to indeed save *two* copies of a reply in case both checkboxes are checked. Would this be a bad thing?
Hello I reproduced this bug with: * Thunderbird version 2 beta 2 (20070116) * Thunderbird version 3 alpha 1 (20070323) This layout would fit best (IMO): [X] Save a copy of sent messages (*) "Sent" Folder on: [Local Folders |v] ( ) Other: [Sent on Local Folders |v] [X] Place replies in the folder of the message being replied to Otherwise, file the copy in where one may choose from two options: * save a copy of the message in the "Sent" folder * save a copy of the in the folder of the replied message and these options should not be exclusive.
Adds FCC3 for placing replies in original message folder Added FCC3 for handling separately "Place replied in the folder of the message being replied to" from FCC. Changed the UI to reflect the functionality.
Attachment #260516 - Flags: review?(bugzilla)
@Beltzner, Scott: this is about probably confusing, new TB2 UI. I'd like your opinion on this... (In reply to comment #7) > What about decoupling those settings? (see bug 359514 - sort of) > With the current indentation, this is suggested anyway. > > This of course would mean to indeed save *two* copies of a reply in case both > checkboxes are checked. Would this be a bad thing? Yes, it would be a *very* bad thing. The point was to *not* save a copy in the "Sent" folder in case the message is a reply. The idea stems from the need to manually clean up your "Sent" folder by filing messages into appropriate folders. If replies were filed automatically (current trunk behaviour with the new pref), you have to do that less often. Therefore, separating the "replies to original folder" setting from FCC would make the new feature introduced by bug 301084 useless. Instead, we should clear up the confusion by doing one or more of the following: a) Change the pref wording to something like "Place replies in the folder of the message being replied to instead of the folder selected above". This would avoid the misunderstanding, but sounds very, very clumsy. I doubt it's possible to find a short but meaningful wording conveying this information. b) Disable the regular FCC user interface elements when this setting is enabled and the new message is a reply.
Igor, I'm going to answer your question from bug 301084 comment 66 in order to rule out misunderstandings. (In reply to bug 301084 comment #66) > - In reply #39: not every message *has* an original message -- how one would > be able to reply to a non-existing message? What is a "pseudo-entry"? It is not about "replying to non-existing messages", it is about "where to file messages that are not replies": In bug 301084 comment 38 (one comment above the one you refer to), Daniel Bachran suggested the following UI: +----------------------------------+ Place a copy in: | "Sent" Folder on emil.hesslow [v] | "Sent" Folder on aaa.bbb | | | Original message folder | | +----------------------------------+ I answered that this UI would be impossible, because not every message *is* a reply. For those messages that aren't, there is therefore no "original message folder". This leads to the question of where a regular, non-reply message would end up if the user chose the third entry in Daniel's UI suggestion. This third entry was the one I meant with "pseudo-entry" - sorry for not being very clear on this back then. So in bug 301084 comment 39, all in all I just explained why the "place replies in original folder" setting needs to be separate from the "Place a copy in" dropdown.
(In reply to comment #10) > Yes, it would be a *very* bad thing. The point was to *not* save a copy in the > "Sent" folder in case the message is a reply. The idea stems from the need to > manually clean up your "Sent" folder by filing messages into appropriate > folders. If replies were filed automatically (current trunk behaviour with the > new pref), you have to do that less often. The issue with separate copies might be seen as a limitation because it is renders itself useless when working with large mails. Nobody wants several copies of a 10MB message spread in different folders (an improvement might be adding references in different folders to a mail, placed in "Sent" by default, instead of creating the copies but this is completely out of current design). So the issue with "copies are a bad thing" is obscuring the possibility of having my own messages kept in threads in different folders and at the same time to have them in "Sent" folder. It happens that I want really bad to see only the messages that have been written by me and I need them in "Sent" folder (again, an improvement may be added with filters and references to mails, some kind of sql style views but it's, again, out of scope). If you are a GMail user, you know how nice is to have your messages placed in threads and also see them in "Sent Mail". With the current design there is no silver bullet and for keeping one feature the other should be neglected or dropped, depending on pov. Unless we come up with something. > Therefore, separating the "replies to original folder" setting from FCC would > make the new feature introduced by bug 301084 useless. Well, no. I actually slightly modified the idea of the features added by bug 301084 (you can find my patch added to that bug also). My patch is just a possible solution to the issue with keeping replies in several folders. > Instead, we should clear up the confusion by doing one or more of the > following: > > a) Change the pref wording to something like "Place replies in the folder of > the message being replied to instead of the folder selected above". This would > avoid the misunderstanding, but sounds very, very clumsy. I doubt it's possible > to find a short but meaningful wording conveying this information. I would change the checkbox to radio button and that would end the confusion in the UI(but I am against this solution) > b) Disable the regular FCC user interface elements when this setting is enabled > and the new message is a reply. a) and b) have in mind "copies are bad" and "keep only one copy". This does not solve anything. I cannot agree with that. This provides policy, not mechanism. Let the user delete the messages he owns and let him keep them wherever he wants. All this nightmare could end with filters and references but I can imagine that someone will find quite a few cons to that.
(In reply to comment #11) > +----------------------------------+ > Place a copy in: | "Sent" Folder on emil.hesslow [v] > | "Sent" Folder on aaa.bbb | | > | Original message folder | | > +----------------------------------+ > > I answered that this UI would be impossible, because not every message *is* a > reply. For those messages that aren't, there is therefore no "original message > folder". This leads to the question of where a regular, non-reply message would > end up if the user chose the third entry in Daniel's UI suggestion. This third > entry was the one I meant with "pseudo-entry" - sorry for not being very clear > on this back then. That UI is a real headache. If Daniel's UI implies that "| |" is a checkbox, this issue with original folder for new messages is easy: ignore unless the message is a reply. The user has the option to check also the "Sent" folder. But this design can create too many copies. The current design has two radio buttons and a checkbox in the same column and that is confusing. What the current design does not say is that the checkbox overrides the radio buttons. Serious issue would be if the option with original folder would be a radio because the user would lose the only copy (unable to check also the "Sent" folder) of a new message. The option with copies of replies should be grouped with radio buttons.
(In reply to comment #12) > So the issue with "copies are a bad thing" is obscuring the possibility of > having my own messages kept in threads in different folders and at the same > time to have them in "Sent" folder. It happens that I want really bad to see > only the messages that have been written by me and I need them in "Sent" folder FTR, Lotus Notes works like that: it does not have a "Sent" *folder*, but a "Sent" *view*, which does not physically hold mails, but just displays them. You can replicate this behaviour with Thunderbird's (and SeaMonkey's?) feature "Virtual folders": Just use the regular search feature, then click the button "Save as virtual folder". > All this nightmare could end with filters and references Yeah, filtering outgoing mail would be really great. Coincidentally, bug 11039 was filed about seven years ago, requesting exactly that feature - but no work happened there (feel free to take that bug). Placing replies in the original folder could be done with that, as well, but implementing only this smaller feature instead of waiting another few years for the bigger one seemed wise to me. That said, let me restate my reasoning for this feature: a) The main goal of mail applications is to help you organise mail, and be configurable to do certain things automatically. b) The vast majority of users, if they use custom folders at all, create a folder for each topic. c) If you care about the size of your "Sent" folder, you clean it up by filing the messages to the topical folder. d) Copies are a bad thing: there should be one physical location of each mail. If it is deleted there, it is in fact deleted. Additional copies in some folder *and* the "Sent" folder make it cumbersome to get rid of mail in an organised fashion. If I combine these four points, it appears to me that it makes perfect sense for us to ship an optional feature that files away replies automatically - and that is exactly what was implemented in bug 301084. All in all, it's surely a matter of opinion. Yours and mine were explained in detail now, but the opinions of Scott McGregor (mail module owner) and Mike Beltzner (Mozilla's UI lead) would be interesting to read, and I guess the decision is up to them. Scott and Mike, what do you think we should do here? UI, functional or no change?
Attachment #260516 - Flags: review?(bugzilla) → review?(mnyromyr)
Comment on attachment 260516 [details] [diff] [review] Adds FCC3 for placing replies in original's message folder Cedric is no owner or peer, so the wrong requestee. Karsten, is there still any validity to this?
Attachment #260516 - Flags: review?(mnyromyr)
(In reply to comment #16) > (From update of attachment 260516 [details] [diff] [review]) > Cedric is no owner or peer, so the wrong requestee. Karsten, is there still any > validity to this? No, this was fixed "visually" in bug 345121 by indenting the fccReplyFollowsParent checkbox one level - although without asking any SeaMonkey person. Obviously, noone complained yet, though. ;-)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: