GNOME Bugzilla – Bug 227718
Delete behaviour should be configurable
Last modified: 2006-09-19 00:37:23 UTC
This may be a duplicate of 584, but since that is marked as resolved, I will open a new bug. This one is a wishlist, and definetly not resolved. The delete behaviour should be configurable in evolution just as it is configurable in netscape. When I use any other mail client and I hit delete, I have it configured so that it moves the message to the trash, then a cron script cleans up old enough messages(30 days). Everything is stored on my IMAP server and I am a happy man. When I use evolution and I hit delete, evolution marks the message as deleted, pretends to move it to the trash folder and hides it from view. From the user perspective, it is almost the same. Until I switch to my web based email client because I am away from my home computer. All I get to see is a folder full of messages marked deleted with undeleted messages, few and far in between. Furthermore my cron script never gets the chance to clean up old emails. Mozilla, gives you three options, mark as deleted, move to trash, remove message. Evolution should let you do the same thing.
Michal, this actually is a duplicate of bug 206061. Basicall, that bug covers the dreaded Trash as vFolder vs physical folder issue. Having an option for a physical Trash folder should implement your feature request. However, I'm not exactly sure about the options you mention briefly in the last sentence, especially the "remove message" option. Just in case: IMHO a "feature" to instantly physically remove the email for good (expunge on the server) on any deletion is a WONTFIX. This would open a whole can of worms and result in lost mail for the users due to accidentially hitting the wrong key. Again, just in case... ;) A useful related feature that already is available independently is View / Hide Deleted Messages, which, when enabled, shows the messages "marked as deleted". All that said... I believe this to be a duplicate. :-) *** This bug has been marked as a duplicate of 206061 ***
Well, it pretty much is a duplicate of 206061, Although I don't understand how automatically deleting an email(like really deleting it) after it was moved somewhere else gonna result in lost mail. the show deleted messages "feature" is really weird. You can hit delete on the keyboard and it slashes it. Now the message is in the trash and the regular folder, and hitting delete in either folder doesn't do anything. I don't understand why that is considered correct behaviour. No other client does this.
(In reply to comment #2) > Well, it pretty much is a duplicate of 206061, > > Although I don't understand how automatically deleting an email(like really > deleting it) after it was moved somewhere else gonna result in lost mail. "Moved somewhere else". That would be the physical Trash folder, no? What is "remove message" (see your original report) supposed to mean, then? Clearly, it can not be moving to Trash. > the show deleted messages "feature" is really weird. You can hit delete on the > keyboard and it slashes it. Now the message is in the trash and the regular > folder, and hitting delete in either folder doesn't do anything. I don't > understand why that is considered correct behaviour. No other client does > this. This is correct. Actually, enabling that feature does show the physical state of the storage. The strike-though is the "deleted" flag, for example when using IMAP. The message itself is not yet removed physically from the backend storage -- just as Mozilla does it, without any option to display this. (Using Moz, the mail still is in its original location, until the folders are "compacted".) Hope that explains thi feature. :) The Trash in Evo currently is just a vFolder. Which in this case holds all mail that is marked for deletion (stroke-though in the original folder, when that feature enabled). So basicaly, the Trash really is just some kind of "view" of your mail right now. Changing this and having the option of a physical Trash folder is what bug 206061 is about. You are correct that "hitting delete" on a mail in the Trash currently does nothing. This is another bug filed already -- desired behavior is to expunge that mail then, which means selectively removing that mail physically for good. (This is hard to accomplish on some IMAP servers, if possible at all, though.) Michal, if you seriously believe your feature request to be actually more than what is covered in bug 206061, please feel free to reopen this bug. However, please try to explain the differences, so we really know what feature is missing. :) Thanks.