User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Build Identifier: version 3.0a1pre (2008050503) When you move a draft message into subfolders of the "Drafts" folder and then edit the draft message and then save it, it saves the new version back into the "Drafts" folder rather than staying in the subfolder where you put it. For people who work on many different draft messages at the same time, being able to organize them into subfolders is very important. Having the draft messages move back into the main "Drafts" folder disrupts this organization. Reproducible: Always Steps to Reproduce: 1. Create a new message. 2. Save the message as a draft. 3. Create a subfolder under the "Drafts" folder. 4. Move the draft message into the subfolder. 5. Edit the draft message. 6. Save it. Actual Results: There are now two versions of the draft message. The old version is in the subfolder where it was located before the save command, and the new version is saved under "Drafts". Expected Results: The new version of the draft message should be saved in the subfolder of "Drafts" where it was located before the save command, overwriting the old version.
Please check tools/account settings/ that very account -copies and folders in the right area see: [Drafts and Templates] "keep drafts in: ...respective folder" now that is the setting that will always tell Tb to autosave and save the Draft in that place (not a subfolder of it) please consider further commenting regarding : -this is normal behavior today and is intended not an error. -if that is wrong and how it should be, but do consider the current behavior as drafts are designed (for example not as "notes") If you thought is just an error, consider the bug as WORKS FOR ME, if the behavior should become different in future, please change severity to "enhancement" and comment accordingly.
Thanks for the comments ovidiu. I am looking for the "keep drafts in: ...respective folder" option, but I cannot find it. I have included a screenshot of my "Copies and Folders" dialog box. Am I looking in the right place? BTW this is version 3.0a2pre (2008051503). Thanks!
I can confirm that the bug still occurs in TB 22.214.171.124. I'd also like to add my thanks to ovidiu for the comments and suggestions. I have tried the [Drafts and Templates] options and that really doesn't do the trick. That allows you to change which folder all drafts are stored in but does not allow you to organize drafts. As for the idea that the current behavior is the intended behavior, let's consider that briefly. Can we imagine a situation where someone would create a subfolder under the drafts folder, move a draft message into that subfolder, subsequently edit it there, and *want* it to be saved back in the main drafts folder? I can't. Perhaps my imagination is limited, but the only reason I can come up with for creating subfolders of the draft folder is to organize drafts. Right now you can create subfolders of the draft folder, but they are completely useless, as far as I can tell. Conceptually, a subfolder of the drafts folder should just be a way to organize drafts, but that is not possible now. I understand resources are limited and someone has to decide this is important enough to fix, and that may not happen, but I can't imagine the current behavior being the desired behavior. For me, this is an important bug.
(In reply to comment #3) > > I am looking for the "keep drafts in: ...respective folder" option, but I > cannot find it. I have included a screenshot of my "Copies and Folders" dialog > box. Am I looking in the right place? BTW this is version 3.0a2pre > (2008051503). I think I misunderstood ovidiu's reply. I was looking for an option specifically called "keep drafts in respective folders", and now that I reread his/her comment, I don't think that that was the intended meaning. Please ignore comments #2 & #3.
Indeed, on 126.96.36.199 and 3.0a1 is the same. The idea is that draft is more of a temporary file as it is treated today. So the organizing procedures are not really working (for example, tags disappear also on the next save etc ..). And by intended behavior I mean it was designed like this. Ok, let's see how to put it: 1. this is incorrect behavior, because -if I'm allowed to create a subfolder it should work as expected. -if it's not supposed to allow normal folder actions, should not allow creation of subfolders, tags etc 2. this is request for enhancement if -drafts need to be used in more than a temporary way (notes etc.) -need for organizing drafts (as they are ..) So, as I see it, current behavior is at least a misleading. If there would be no subfolders creation, you may ask for it or other organizing elements, but being there creates expectation for normal folder behavior, which is not the case. And this should relate to other restructuring or issues on folders.
This is not a bug. The current design allows for one Drafts folder per identity (each "From" value), and it is working correctly in saving the newly edited draft in the Drafts folder for that identity. I suggest that this is an enhancement request; you want to allow multiple Drafts folders per identity.
I would invite Brian to visit my comment #4 above. I cannot see how the current behavior makes any sense. If Brian does, I would very much appreciate learning how it would be useful to create a subfolder under drafts, move a draft message into the subfolder, edit the draft, save it, and have it reappear under the main draft folder, not the subfolder. If Brian can explain under what scenario this sequence makes sense, I would dearly love to be enlightened. Also, let me clarify how I see the draft subfolders being used. I do *not* see them being used to create notes. I see them being used to organize the creation of multiple draft messages. Each month I send out batches of messages. Some of these messages go to one organization. Some of these messages go to a different organization. While I am creating and editing these messages, I would like to keep them in separate subfolders so that I can easily access one set of messages or the other or even turn over one set to another person for final edit. As ovidiu points out, being able to create these subfolders creates the expectation that I can when for practical purposes I really can't.
A sub-folder of Drafts folder is just a folder. It is not a Drafts folder. Each identity can have one Drafts folder, which is the target for saving messages from the message editor. Moving or copying the messages to another folder does not change the Drafts folder definition. When the message is re-opened in the editor, the source folder is forgotten. I agree that it could be useful to have multiple Drafts folders, or for the editor to "remember" the folder, from which the message was loaded, as the default save target. I am just pointing out that this is not a bug, but an enhancement. It is working correctly, but could be improved.
Brian, I respect your position on this. But I think were looking at this completely differently. Let me put it this way. If the design results in a behavior that makes no sense, that confuses people and is counter-intuitive, does it really make sense to still say "not a bug", "working as designed"? The part that I have not heard you address is that we're not talking about just any old folder anywhere becoming a draft folder at will. We're talking about *subfolders* of the *drafts* folders. I would really like to hear your explanation of why subfolders of the draft folder should not be expected to behave identically to the draft folder - why the user should not be surprised and confused when they do not. I have written a lot of user interfaces myself. Personally, any behavior which surprises and confuses the user I consider a bug, even if it meets some arbitrary criteria of "as designed". Are you saying that the TB philosophy is that as long as the behavior meets some strict, legalistic definition of design requirements, then the confusion and consternation of the user is irrelevant? Then I pity the users. Sorry for the passion. I get pretty worked up when it comes to UI's and the interests of the users. Peace!
First, I don't speak for the Thunderbird developers (I am not even one of them), so what I say is just my opinion, not some official position. Basically, I don't find the current behaviour to be at all surprising or confusing. * When you save the message, it is saved to the Drafts folder, exactly as expected. * When you move the message to another folder, it is no longer treated as a draft (e.g., double-clicking opens a message window, not the editor; sending the message does not delete the original). I do not expect a sub-folder of a drafts folder to be treated any differently than any other folder. I acknowledge its value, but as a user, it never crossed my mind. (I used multiple Drafts folders in one of my accounts, but each was named uniquely and was at the top level of the account.)
(In reply to comment #11) > * When you move the message to another folder, it is no longer treated as a > draft (e.g., double-clicking opens a message window, not the editor; sending > the message does not delete the original). This is incorrect. Drafts moved to folders outside of Drafts are no longer treated as drafts; drafts moved to subfolders of Drafts *are*. For example, the "Edit Draft" button is displayed for messages in subfolders of the Drafts folder (but not for messages moved to folders outside of the Drafts folder), which IMHO clearly implies that messages in subfolders of the Drafts folder are still considered to be drafts.
I accept the correction. Apparently, the message opening behaviour is inherited. I even tried moving the folder out from under Drafts and back to observe the changing behaviour. I wonder whether this was intended by the developers, or is a useful accident.
The whole point is that as it currently stands it is not a *useful* accident or design, whichever the case may be. Saving edited messages of subfolders of drafts back in drafts makes subfolders of drafts completely useless. So being able to make subfolders of drafts is just a frustrating teaser.