After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 227718 - Delete behaviour should be configurable
Delete behaviour should be configurable
Status: RESOLVED DUPLICATE of bug 206061
Product: evolution
Classification: Applications
Component: Mailer
unspecified
Other other
: Normal enhancement
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2002-07-12 16:47 UTC by Michal Palczewski
Modified: 2006-09-19 00:37 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Michal Palczewski 2002-07-12 16:47:04 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.
Comment 1 Karsten Bräckelmann 2006-09-18 23:15:45 UTC
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 ***
Comment 2 Michal Palczewski 2006-09-19 00:11:13 UTC
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.
Comment 3 Karsten Bräckelmann 2006-09-19 00:37:23 UTC
(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.