GNOME Bugzilla – Bug 206061
Allow normal, non-vFolder, Trash and Junk folder
Last modified: 2012-12-24 16:46:57 UTC
Evolution insists on managing Trash as a "magic" vFolder with certain additional special properties and hooks into the GUI. I would prefer to have Trash as a simple, normal folder. When I delete a message, I would like the following two things to happen: 1. Copy the message into the designated Trash folder for that account. 2. Mark the original copy of that message as deleted. In other words, I want the option to treat message deletion as a move into a designated Trash folder. Yes, I realize that this is slower than just turning on the "Deleted" flag for the message. Yes, I realize that may be less space efficient, because there may be two copies of the message until the next expunge. Yes, I realize that "Undelete" may be impossible on some backends, because a non-virtual Trash folder may not be able to remember where a message came from. Yes, I realize that this may offer less functionality that the current vFolder-based approach. In spite of all of this, though, I still want the feature. It offers improved interoperability with other mail clients, and also makes it much easier to periodically rotate Trash out into an archival area. The only holes in my mail archives were created when I made the mistake of using a client that lacked a "move to Trash folder" feature. I don't use such clients any more, because it's too easy to forget and do the wrong thing and create gaping holes in my archives. Many other popular mail clients offer this as an option, and Evolution should do the same. It doesn't need to be the *only* way, it just needs to be available as an option. Choice is good.
*** bug 211165 has been marked as a duplicate of this bug. ***
*** bug 206339 has been marked as a duplicate of this bug. ***
*** bug 210409 has been marked as a duplicate of this bug. ***
*** bug 217127 has been marked as a duplicate of this bug. ***
*** bug 219006 has been marked as a duplicate of this bug. ***
*** bug 213422 has been marked as a duplicate of this bug. ***
*** bug 217877 has been marked as a duplicate of this bug. ***
I'm really not sure this is such a good idea. It certainly isn't a serious priority, since it doesn't provide a huge benefit compared to the amount of work it would require. But even if we were to get to this bug, "Other mailers do it this way" is not the best reason to do things, especially since the virtual-trash method is more efficient, as you admit. Should we take a step backward in speed and efficiency just because other products are slower and less efficient? If you really really really want a second, physical copy of the messages you delete, I suggest that you create a folder named "MyTrash" and, whenever you want to delete an item, just drag it to the "MyTrash" folder. Alternately, you can periodically copy any items you want to save from the virtual trash into your physical "MyTrash" folder--- say, before performing Expunge on any folder or especially before emptying the trash (that is, expunge on all folders). Another solution is to not delete things that you want to keep-- put them in an archive folder.
Aaron Weber wrote: > it doesn't provide a huge benefit compared to the amount of work it > would require. It will come as no surprise that I respectfully disagree. (Emphasis on the "respectfully" here. This is a disagreement, but I genuinely admire you guys and the work you do.) > "Other mailers do it this way" is not the best reason to do things, > especially since the virtual-trash method is more efficient, as you > admit. Please consider as well the issue of interoperability. In a world of multiple e-mail clients, "other mailers do it this way" is a very good reason to do things. I use several different mail clients on a regular basis. The fact that I can do this is a testament to the strength of formal standards (e.g. the IMAP protocol), but it also depends on widespread adoption of informal conventions. One of those conventions is the *option* to delete messages by copying them into a real folder named "Trash". Not only is Evolution unable to cooperate in this realm, it doesn't even let me view that folder. > Should we take a step backward in speed and efficiency just because > other products are slower and less efficient? Yes, we should. If the user wants us to, we should. Recall that the first word in this bug report's summary is "allow". I'm requesting this as an *option* for those users who need interoperability among multiple mail clients. This is not a step backward in speed and efficiency. It's a step forward in functionality and in respect for your users' needs. Look at the list of bugs marked as duplicates of this one. At least eight of your users want this feature strongly enough to have gone through the trouble of filing a Bugzilla report. Eight. Perhaps not many by itself, but consider that as a sample of the larger user community, many of whom will not report their wishes. For those of us dealing with a mixed, multi-client e-mail world, this is anything but a step backward. > If you really really really want a second, physical copy of the > messages you delete, I suggest that you create a folder named > "MyTrash" and, whenever you want to delete an item, just drag it to > the "MyTrash" folder. Try that for a few days and tell me if you like it. Seriously, try it. I tried it. I *really* want to use Evolution, so I tried to do just this. It's unworkable. Consider this from a usability standpoint. Trashing a message as you suggest requires the following sequence of actions: 1. Select message. 2. Click on toolbar icon for moving messages. 3. Dialog box appears. Scroll down to "MyTrash" folder. Note that scroll position is not retained, so you have to scroll down to this folder anew each and every time. 4. Click "OK". There are some slight variations, e.g. using the popup menu or selecting Actions -> Move to Folder. And I believe you were suggesting keeping the folder menu pinned open, and using drag-and-drop. But the point here is that there's a fair amount of work involved, no matter which way you do it. Consider as well how difficult it would be to perform this common task using just the keyboard. Compare that to using Evolution's standard deletion mechanism: 1. Select message. 2. Click on deletion toolbar icon, or press <Delete> key. Note that the standard deletion mechanism is more convenient in general, and also far more keyboard friendly. Seriously, try using the approach that you suggested for a few days. I think you will find it terribly cumbersome. > Alternately, you can periodically copy any items you want to save > from the virtual trash into your physical "MyTrash" folder--- say, > before performing Expunge on any folder or especially before > emptying the trash (that is, expunge on all folders). Too dangerous. Remember, interoperability is an issue here. *Many* other e-mail clients treat expunging as an operation they may choose to do at any time to "compact" a folder with many deleted messages. If I follow your suggestion and use Evolution-style deletion with periodic manual archiving, it's just a matter of time before some other e-mail client decides to expunge and blows a hole in my mail archives. I'm not just speculating here; I'm speaking from experience. The only holes in my mail archives were created when I made the mistake of using clients that lacked a "move to Trash folder" feature. I don't use such clients any more, because it's just too easy for either the user or the software to do the wrong thing. When the "wrong thing" results in irretrievably deleting users' mail, that's a really bad move. > Another solution is to not delete things that you want to keep-- put > them in an archive folder. Right, this is what you suggested earlier with a MyTrash folder. As I said, I've tried to convince myself to use such a model, but I find that the user interface interactions are just too cumbersome in practice.
Here's my situation. I have my INBOX and then a folder called 'read' that I put messages into when I've dealt with them. I have a filter set up like this: if message is marked read, move it to 'read'. Then when I've dealt with a message in INBOX I select it and hit Ctrl-Y, and it's moved into the read folder. Or if I'm reading a bunch of messages, I select them all and hit Ctrl-Y and they're all moved. I've found this to be a pretty easy shortcut for this common operation.
Because of vTrash, Evolution is nearly unusable for receiveing high volume mailing lists. I have filters shoveling email out of my IMAP server. However, the filters don't actually permanently delete any email from the IMAP account. Instead, they leave behind messages that are marked deleted. There is NO WAY to automatically expunge the deleted messages from the IMAP server. This means that, every couple of days, I have to MANUALLY EXPUNGE the IMAP account. Otherwise, the IMAP server will start DROPPING EMAIL. I'm away for a few days and, unless I unsubscribe the mailing lists, I LOSE a bunch of PERSONAL EMAIL and get KICKED OFF a bunch of MAILING LISTS. That is INFURIATING and it has already happened to me several times. [Sorry about all the capital letters but I'm pretty ticked off about this.] The solution is obvious: Add a real Trash folder in place of vTrash an d put the manually deleted messages there, and have all the other crud expunged automatically. Could we PLEASE have a solution to this problem already?
you seem to not understand the problem. Having a physical Trash folder would not solve your problem at all, I fail to see how it would. If I understand you correctly, your complaint is that your IMAP server runs out of space, yes? Well, moving the messages to a "real" Trash folder instead of marking them as deleted in the original folder isn't going to somehow use less disk space on the server. ...so this argument is for nothing.
I'll try to make it simple: 1) When I (manually) delete a message I want it to go to a (real) Trash folder, from where I can recover it should I need it. I also want to empty the (real) Trash folder manually, at my leisure. This is pretty normal. 2) When a filter moves a message from one folder to another, I want the message in the source folder to be marked deleted and expunged automatically by Evolution. I do NOT want to manually expunge it. In fact, I don't EVER want to see it again (expect in the destination folder where it was moved). In particular, I do NOT want to see it in my Trash folder. Currently, expunge empties the vTrash folder, which makes the vTrash approach an obstacle against having an automated expunge function. I.e., I can have 1) or 2) but not both. With a real Trash folder I could have both. Clear now?
*** bug 273082 has been marked as a duplicate of this bug. ***
@ Aaron Weber 2002-08-13, if you dont want to change the system by default just because it would behave like others, make it an option. Iam sorry for writing a separate bug thats now a dup if this one, i havent found this one here, i didnt expect it to be a problem that lasts since 2001 now. A virtual trash is nice and fast - but only if you just use one computer to read your emails and you dont use imap, cause this virtual mails will stay on your online folder when you delete them! e.g., i use Evolution with IMAP on two machines and the online web service. If i delete a message in evolution, it goes to vTrash. but i still see the message on the other systems. Thats not what i wanted, i wanted to delete it. And, i want this message to appear in my "mydeleted" Folder. Iam sick of moving them manually, evolution has fancy icons for the Trash, but its not usable here. Is there a chance anyone starts fixing it? Are there more people like me using IMAP?
We've got this function in the Evolution Settings -> Mail Preferences -> "Emtpy trash folders on exit [every Time, once per day, once per week once per month]" Perhaps we could extend this with: "Move trash folders content on exit [every Time, once per day, once per week once per month] to folder [show local folders, and IMAP folders]" That would be a good compromise or what do you think?
*** bug 263455 has been marked as a duplicate of this bug. ***
Created attachment 51123 [details] Two Trash and Junk folders appear because Evolutioon displays virtual folders regardless of existing ones
Comment on attachment 51123 [details] Two Trash and Junk folders appear because Evolutioon displays virtual folders regardless of existing ones I would like to see Evolution have the option of using an existing Trash folder and Junk folder. As I use multiple mail clients I already have a Trash and Junk folder. I also have rules on my mail server that deliver certain messages to these folders automatically. This could be handled the way Netscape Mail used to handle it - right click the folder - properties - and tell it this is your Trash folder, or Sent Mail fodler, or Junk, or Drafts, etc... I am attaching a screenshot of the confusion caused by Evolution not using the existing folders. A picture says a thousand words.
*** Bug 311915 has been marked as a duplicate of this bug. ***
Similar to the Trash "vFolder vs physical folder" issue, the same gets requested or asked about frequently on the mailing lists for the Junk folder. Adjusting Summary to cover both similar cases.
*** Bug 324117 has been marked as a duplicate of this bug. ***
*** Bug 326909 has been marked as a duplicate of this bug. ***
See bug 326909 for some insightful comments. Especially see bug 326909 comment 0 and attachment 57310 [details] [review] for a patch that adds this option.
In the future we will likely have to move to physical Trash and Junk folders because of problems like the one described in bug #336076
*** Bug 336076 has been marked as a duplicate of this bug. ***
and because of bugs like the one described in bug #302915
I'm bumping up the severity of this to at least normal, unless there are any serious objections. The lack of a normal trash/junk folder causes the unread message counts to act very funny, which required a fix which caused #336076, which in turn causes evolution to take tens of minutes just to check for new mail. This is making evolution completely unusable for a number of people, not to mention the interoperability arguments with other clients. To the users I've spoken with, this is very much a "Urgent -- This bug blocks usability of a large portion of the product, and really should be fixed before the next planned release." issue, and I'd suggest that it be marked as such. The benifits of vfolder-based Trash and Junk folders (namely, the ability to return a message to its source folders if it's undeletede), seem to be achievable by storing information about the source folder (perhaps only until the message is expunged?)
(gah, marking bugs as duplicates makes this comment log look ugly... oh well) Anyways, my feeling is that even tho I personally love vTrash (I could care less about vJunk as I feel Junk filtering is a server job, not a client-side job - at least in the case of IMAP), it would probably make a wider range of people happy if they just had their physical Trash/Junk folders like other mailers. as it is the path of least resistance. It's sad for me to consider losing my beloved vTrash folders, but it's clear that vTrash cannot be fixed to work properly with the functionality demands of many users.
Jeremy: yea, I agree it probably deserves a Normal bug priority (certainly "enhancement" is no longer suitable)
I just want to add some more info to this long lasting discussion. As Jerry correctly said Junk filtering is a server job, so you've also have to think about server side Spam folders. My provider uses in addition to the regular Spam detection system a dynamic Spam detection, based on my inbox (automatic whitelist) and Spam folders (automatic blacklist) content, which is very efficient. Just mark a message as Spam reduces the filters efficency, because if mails with subjects like Viagra or Pr0n are in my inbox, new ones are handled as desired messages. This is a very odd behaviour. Ok you can blame my provider for such a crappy implementation, but a good configured client (Thunderbird in my case) copes perfect with it. ;) At the moment I just can use Evo for PIM tasks, but I'm really looking forward to get rid of this redundant Thunderbird.
I find it unbelievable that Evolution *still*, after 5 years of this bug being open, will not offer the option to use a Physical Trash folder. Like the many other people that have commented on this already, I use several mail clients, and the simplest way to have them cooperate in deleting messages is to move them, immediately, to an IMAP trash folder. Like others, I understand that this is not the most technically elegant solution. I don't care - it's what will work in my environment. I looked at this same bug entry three years ago and decided I wouldn't use Evolution because of it. I'm doing the same thing today.
*** Bug 227718 has been marked as a duplicate of this bug. ***
Created attachment 73009 [details] screenshot of webmail As a result of this bug many webmail programs are completely unusable. Here is a screenshot of IMP webmail. Openwebmail reacts this poorly as well. I have 16 emails hidden in 28 pages of junk and deleted mails. Despite Evolution showing only 16. Evolution shouldn't assume that it is the only client. You would be very hard pressed to find the one undeleted not spam email in this bunch. And if mail wasn't preprocessed with spamassasin you would have an even harder time finding it. email addresses have been pixelized to respect the senders privacy.
*** Bug 396503 has been marked as a duplicate of this bug. ***
any *evolution* with this issue? :-)
This bug is a show stopper. As mentioned before using different mailclients and especially webmail on an account is a pain with Evolution involved, so I still have to use Thunderbird, which unfortunately doesn`t include in Gnome very well. Is there any hope this issue will be adressed soon?
I consider having the possibility to permanently delete a message from a folder should be a "must be" in a "product" like evolution.
2001-08-02 09:38 ? Anybody home yet? Just for the record, I would appreciate this feature too.
The same problem exists for the Junk folder. Every time I login onto my IMAP server using another client or Webmail I have two Junk folders and two Trash folders in Evolution because of this... See Bug #471486
*** Bug 471486 has been marked as a duplicate of this bug. ***
Another new version of Gnome, and another update to Evolution. This bug is still not fixed and once again and I am forced to go back to Thunderbird. Really quite disappointing. It's not that Thunderbird is a bad application, but it doesn't have stable calendar integration. Would a bounty help? Does anyone feel strongly enough about this to put up some donations to help fix this bug?
This has been bugging me since I started using Evolution. I can deal with the Trash folder as is (though I still won't like it), but the Junk folder just makes no sense locally. My server already has a Junk folder that it moves stuff it thinks is spam into, and it learns from any new messages I dump in there manually - I can't think of a good reason why Evolution wouldn't use that server side Junk folder (like it does with Drafts and Sent).
I also request to be able to use server Trash and Junk folders. I recntly installed Fedora 8 and gave another try to Evolution. It seems that since my Junk and Trash folders are messed up I will have to go back to other mail clients.
Also I *really* think this should be consider as a bug not an enhancement and it should have a higher priority than Normal but it's just my opinion.
What obstacles are preventing this bug from being addressed over 6 years after filing? It's preventing the correction of one urgent/major bug (#336076), and significantly impacting evolution's use in interoperation-sensitive environments. Between the bug's age, relationship to high-priority bugs, and indication that it's not playing nicely with other apps, should there be some consideration of how to prioritize attacking this one? How should it's priority and severity be considered? Is anybody actively working on ways to get around this? Are there any known workarounds?
I'm the original reporter of this bug, over six years ago. My workaround? Use another mail client while waiting in vain for some movement on this bug. :-(
Only "Actual Trash & Junk Folders" are available for Exchange and GroupWise providers as their respective proprietary clients (Microsoft Outlook and Novell GroupWise client) supports only actual Trash & Junk folders. There is no VFolder for Trash/Junk in GroupWise and Exchange Providers. IMAP does not have a move command. So if you want to enable support for actual Trash/Junk you have to make a copy and delete operation; then expunge the deleted mail. This does not augur well with performance, if you delete a lot of mails in a folder with a lot of mails. And think of the mbox rewrites associated with the mail-move operations. The author(s) of IMAP RFC have even stated that Actual-Trash is a violation of IMAP RFC. (1) "On this computer" was modeled in the same way as IMAP because of the benefits provided by VTrash and VJunk. However, if you are so keen to using actual Trash and Junk folders, you can do so via move-mail operation or using message-filters. Given the number of people who filed this req. and since "XYZ mail-clients are supporting it why not Evo" , In my free-time, I'll be writing a plugin which will: Move mails to trash/junk based on marking for deletion/junk This plugin will not be enabled by default though. Also, if somebody cooks up a patch for this before I do, it is always welcomed :) (1) - Interesting Read - http://mailman1.u.washington.edu/pipermail/imap-use/2006-March/000118.html
Created attachment 99009 [details] Filter Condition Screenshot for Actual Spam You may have to apply the filter yourself though.
Just to make one thing clear. I am not annoyed bu the vFolder thing. What I consider a bug is that if I have an actual Trash and/or Junk folder on my IMAP server (and for Trash it comes from my ISP I have no choice here) everything is messed up. Maybe there could be an option to chnage the name of the vFolder or maybe they could be *really* virtual and not interfere with *real* folders having the smae name. My 2c.
Indeed. The problem is not the existence of the vFolder. The problem is that it is abusing the IMAP server's namespace, and unconditionally obliterating _real_ folders which may happen to have those names. vFolders live in the vFolder part of the folder tree, which is conveniently located right at the very bottom of the tree, where it can be forever collapsed. My answer to this problem, for the last few years, has been http://david.woodhou.se/evolution-data-server-1.2.0-vcrap.patch If I want a vFolder which shows me all \Deleted messages on a given IMAP server, I'll create one. In the right place.
Created attachment 99072 [details] Fix Via Plugin I am not in favor of yet another UI parameter, to the already horrendous preferences dialog. Involves lot of doc. rewrites, confuses the user etc. I implemented a plugin which when enabled, will disable vtrash and vjunk for all IMAP accounts. I'll commit it after playing around with this for some more time. I have to implement "self-disabled plugins" in evo plugin framework and this plugin has to wait until then. If someone is trying this, make sure to "return 0" in e_plugin_lib_enable function.
I should have mentioned that it is a partial fix just to hide the VFolders. Mapping del to move-operation and choosing folders for trash/junk isnt complete yet.
How the protocol was designed and how 99% of imap clients work today are very different things. If we're not going to have a real junk-mail folder, and instead use vfolders only, I have three questions: 1) How do we get interoperability at a UI level with server-side junk filtering, where junk is filtered into a seperate folder automatically? How do we interoperate with a server configuration where users mark messages as spam by moving them into "Confirmed Spam" folder? 2) How do we get new/old message counts for folders without downloading their headers to check if each one individual qualifies towards the message count? This behavior in particular is making evolution perform dismally compared to its competition. (Details in #336076). 3) How do we interoperate with the majority of other clients in the world that do follow the convention of real trash and junk folders?
> If we're not going to have a real junk-mail folder, and instead use vfolders > only, I have three questions: > > 1) How do we get interoperability at a UI level with server-side junk > filtering, where junk is filtered into a seperate folder automatically? How do > we interoperate with a server configuration where users mark messages as spam > by moving them into "Confirmed Spam" folder? A while back there was a patch to make sure that the vTrash/vJunk folders did not hide the real Trash/Junk folders. This is a pretty simple solution to this problem... I guess someone just needs to apply this patch or re-implement the patch if my memory is off. > 2) How do we get new/old message counts for folders without downloading their > headers to check if each one individual qualifies towards the message count? > This behavior in particular is making evolution perform dismally compared to > its competition. (Details in #336076). We don't have to download all of the messages, we just have to have their flags, which we need anyway to display the folder. > 3) How do we interoperate with the majority of other clients in the world that > do follow the convention of real trash and junk folders? Well, if #1 is fixed, then this is no longer a problem, right? Sankar's patch seems like a nice solution as well, in place of the patch I was thinking of for #1 (which admittedly could be confusing I suppose, unless we had different icons for them?) Sankar's patch sounds similar to David's patch, basically, except that it is a plugin. So overall, everyone wins.
... 4) How will we be able to have trashed messages deleted automatically after they have been in the Trash for N days? Requiring trashed messages to be deleted (a) manually and (b) all at once, regardless of age, is not humane regardless of what the Imap specification says. (The equivalent for Nautilus is bug 149572.)
Hello gentlemen, I cannot figure out how to use the Trash in Evolution properly. I do not care one way or the other about the vFolder, but the deleted flag is not implemented consistently. Perhaps a kind person could take a minute and walk me through. My employer, an insurance company, makes me archive all emails. When I move messages from the Trash to a "2008 Received Items" folder the messages continue to be flagged as deleted. Now I have two copies in the Trash, one belonging to the Inbox and one belonging to "2008 Received Items." That makes no sense to me. Evolution should move the messages (and not copy them) and unset the delete flag. What other means are there to move messages out of the Trash? Why does the program allow me to move them if it does not work? Alternatively, can I set up a custom button (like a delete button) to move messages to a designated folder for archiving? How do you guys do that? Thanks for your help. I apologize if this is not the right place to ask, but I have over ten years of Linux experience and you guys know what you are doing.
> Evolution should move the messages (and not copy them) and unset the delete > flag. move always *means* "copy & delete the original".
+1 vote. Please developers. Create one method to we can use a real folder instead of vfolder. My webmail doesn't like of evolution vfolder. Thanks
*** Bug 484439 has been marked as a duplicate of this bug. ***
Are you dead or are you deaf? We all know that Evolution does it the right way from some point of view: http://deflexion.com/2006/05/imap-way-of-deleting-message So, nice for all the people having a setup IMAP assumes to handle well, but the main reason for using IMAP in my case is to have my mail in sync (means several folders, deleted mails in my trash folder, junk in my junk folder), wherever I am and whatever client, OS or device I am using. Evolution downloads tons of "deleted" messages to my mobile phone, using my mail-providers web interface is a pain with all those strikethrough mailheaders around and having several Junk and Trash folders in evolutions own interface just makes me sick. I know, my provider sucks, because he didn't implement IMAP the right way, my mobile phone and my telephone company suck because they make it so expensive and time consuming to download all that crap and I suck because I hate messed up interfaces with redundant folders (thanks to vfolders) and keep doing things the way I prefer. Getting serious, why can't you accept that there are lots of people with setups that perfectly work as long as we can use our own and maybe not standard conformant way of handling deleted mails and junk (spam filtering is done on server side in my setup). Unfortunately Thunderbird (which some doesn't handle IMAP right, on the other hand it serves my personal needs very well) is not a perfect replacement because it does not come with decent calendar and address book integration into Gnome. Appologize my poor english and bad manners, but whenever another fresh Ubuntu release comes with Evolution again I hate you and I had to tell. :(
Torben: Thanks for personally offending. Evolution is open source, get your lazy ass up and provide a patch, okay? For your interest: http://live.gnome.org/CodeOfConduct (If people start talking to me in such an offensive way, I can do that too. No problem at all, dude.)
I am really sorry, did not want to personally offend you. It would have been better to cool down before posting here. You are right, I have nothing to contribute, neither code nor new information. It was just - well- 7th anniversary and no hope for improvements, but that does not excuse bitching around here.
Torben: No problem, and I can understand that frustration... :-/
So, there's a patch and a plugin, both of which (to my naive eyes) seem to do the same thing: disable the junk/trash vfolders. The last comment from Sankar P (exactly one year ago) said the actual copy/del operations were missing. If one (say, a newcomer) is to jump in and try do create a patch, what exactly is missing here (either to complete the plugin, or to add the choice to the program)? Would any developer give any help or mentor the creation of such patch in any way? Perhaps at least pointing out what has to be done and in which files?
If it is a design decision, then close it as WONTFIX.
Created attachment 135954 [details] eds part
Created attachment 135955 [details] evo part
(In reply to comment #67) > ... This is some initial work, you can configure real trash/junk folder for IMAP, (oops, I forgot to add check for non-Inbox and non-typed (empty type only) folder for them) and things with it works basically as follows: a) deleting a message moves it to trash folder b) if deleting in trash folder, message is expunged c) no undelete or such d) marking message as junk moves it to possibly configured junk folder e) no move on "not a junk" click f) Folder->Expunge expunges all messages, not only those marked as deleted g) kinda slow for mass operations (except of f)) The "move" here means real move, it expunges source folder from the moved message, thus only one copy on a server is left. It obviously needs some polishing, but I'm not sure where to look and what to touch.
Created attachment 135960 [details] account editor Also realized the change in an account editor requires evolution's restart. I think there's other report about that and even if not, it's out of scope of this bug anyway. Just good to know.
Great work. At the moment I'm running a patched evo 2.26.2 with your changes, it seems to work. Thank you a lot.
(In reply to comment #73) > Great work. At the moment I'm running a patched evo 2.26.2 with your changes, > it seems to work. Thank you a lot. Thanks for testing. Do you also see those issues I mentioned in comment #71? Mainly the slowness, I meant.
I did not yet see any performance regression, but maybe because I'm not dealing with very large directories (my imap-account has as of today around 1000 Mails in two folders, daily I get around 5-10 messages that are worth storing and around 20 spam mails). What I've mentioned is that mails that are automatically filtered into the imap spam folder are not counted as spam-mails when opening the spam folder, therefore the summary shows that in the folder are eg. two mails while there are actually 20.
(In reply to comment #75) > What I've mentioned is that mails that are automatically > filtered into the imap spam folder are not counted as spam-mails when opening > the spam folder, therefore the summary shows that in the folder are eg. two > mails while there are actually 20. Strange, I had it there, but disabled the unset of the flag before moving the message. + res = CAMEL_FOLDER_SUMMARY_CLASS (camel_imap_summary_parent)->info_set_flags (info, flags, set/* & (~CAMEL_MESSAGE_JUNK)*/);
(In reply to comment #60) > > Evolution should move the messages (and not copy them) and unset the delete > > flag. > > move always *means* "copy & delete the original". Which, unfortunately, is exactly why the vTrash system is broken conceptually: Moving an email from, say, Inbox to Archive, makes it also appear in vTrash.
Still no fixes in 2.26.x. Since this blocks another major-severity bug, I'm increasing the severity of this one accordingly.
It's still an enhancement request.
It _used_ to use STATUS, and now it doesn't and it's fairly unusable in some circumstances. That's a regression, not an enhancement request. Personally, I've taken to using PINE to read my email while I'm on GPRS or other slow links, because Evolution is now so bad.
Thanks, Milan for the patch. I'll try to make some time to test it this weekend or the next. Is this patch going to be included in the next evolution release?
(In reply to comment #81) > Is this patch going to be included in the next evolution release? No (or "not yet"), otherwise this bug report would have the status "RESOLVED FIXED".
Does this patch allow us to choose _neither_ the current bogus Trash/Junk folders _nor_ a real Trash/Junk folder? All I want to do is use IMAP as it was intended. I'll mark a message with the 'Deleted' flag when I want to mark it for deletion, and I'll expunge the folder when I want to expunge it.
(In reply to comment #82) > No (or "not yet"), What's required for that, then? Is it still in time for testing? What can one do to help?
As I wrote in comment #71: > g) kinda slow for mass operations (except of f)) the slowness can be a problem. Thus yes, more testing is needed, it's possible it was just my local issue, not an issue with patches as they are. (In reply to comment #83) > Does this patch allow us to choose _neither_ the current bogus Trash/Junk > folders _nor_ a real Trash/Junk folder? No, there is always a real or virtual trash/junk folder. I think fully hiding them does the plugin patch by Sankar.
bug 351413 dupe ?
(In reply to comment #86) > bug 351413 dupe ? Yes, please, close the other.
I think my recent enhancement request at 593947 is a dupe for this request, so I'm putting my comments here. I read through all of the comments and I want to respond to the developer in comment #31. I do not think you need to lose your beloved virtual trash. Couldn't there be various delete options where using virtual trash is one of them? I don't see why comment #83 shouldn't be an option either. There are many scenarios here and we all have our favorite. Mine favorite of course is to "move" deleted messages to an IMAP folder called Trash, or I wouldn't be posting a comment here. After reading all the comments, here is my suggestion for the interface: Inside of account editor "Defaults" tab are the following options: ------------------------------------------------- When deleting messages: (*)Mark as delete then hide. ( )Mark as delete and show messages marked for deletion ( )Mark as delete and show messages marked for deletion in virtual folder named:[MarkedDelete] <--- textbox or button to select virtual folder name. Messages marked for deletion will be permanently deleted when folders expunged. [x]Back-up messages marked for deletion in Trash folder: [Button to select Trash folder would be here with the locally-stored Trash folder as default] ------------------------------------------------- The () are radio select buttons with the first one selected by default. The [] is a check box that is checked by default. Any message in a Trash folder needs to be handled differently than all other folders because it should not be backed-up or you could never delete stuff from trash. I will gladly make a png mock-up of this if developers want it and attach it here. Of course, "move deleted messages to Trash" is what I originally wanted, but I now understand that my messages were never really "moved" anyway. At least with this suggestion, I could still preserve how trash is handled across all of the IMAP clients I use.
*** Bug 351413 has been marked as a duplicate of this bug. ***
(In reply to comment #88) > After reading all the comments, here is my suggestion for the interface: > > [...] While this technically allows the two desired options (virtual and real Trash folders) and many others, the technical nature of the language used would make it almost impossible for users not familiar with the technical details of email storage to correctly change these settings. As I see it the only real option for the non-advanced user is the 'real Trash' option (i.e., it has the lowest number of surprising side-effects), so in my mind the first choice would be between that and all the other options.
I've just tried evolution out again after some time. The problem still applies, and it still causes the issues in the other bugs this blocks, including the "major" severity imap performance bug that seems to put off so many potential evolution users. In isolation, it's an enhancement request. In the larger picture of what evolution is supposed to be, it causes major distress, functions distinctly from other applications that speak the same protocol, and breaks integration and synchronization with other applications. Yes, evolution is behaving as designed. Unfortunately, this is an incorrect and disruptive design choice.
Just noticed this also blocks #507018, which presents problems using evolution with gmail's imap service, and its 2 duplicates.
*** Bug 507018 has been marked as a duplicate of this bug. ***
I just contacted the evolution-list mailing list about the issue: http://mail.gnome.org/archives/evolution-list/2009-September/msg00248.html
Created attachment 144281 [details] Script to move deleted mail in all folders into a real Trash folder This script moves all messages marked 'deleted' in all folders into a real Trash folder, then expunges. You'll need to update the USER constant at the top, and might need to update the TRASH constant. Note that as a result of move being implemented as copy-then-delete, moves causes duplicate messages in Trash, or one copy in Trash and one in the destination folder. Oh well. I thought folks might find this helpful as a (admittedly lame) workaround until Milan's patches get included.
*** Bug 329946 has been marked as a duplicate of this bug. ***
Still present in 2.30. Gmail works right in virtually all modern MUAs, except evolution. Even if what they're doing isn't technically the best-practice for how IMAP works, it's the way it is, and it's not going to change. Three options: 1) Grow, and use IMAP the way everyone else does it. 2) Have a new protocol instead of IMAP, which is "IMAP for Gmail" 3) Don't do anything, and just leave evolution broken for Gmail users. Given that the mailing list thread hasn't gone any whore, and Milan's work is not getting any closer to accepted, afaict, this is a major problem for evolution gmail users. It's not an "enhancement" request, it's a "I would like this mail client to not exhibit incorrect behavior" request. I'm setting this to "minor" at least, since that's the importance assigned to the various bugs that have been marked as duplicates of this. This still blocks 336076, which is high/major. Should "Should operate properly with Gmail" just be a seperate bug?
(In reply to comment #97) > Should "Should operate properly with Gmail" just be a seperate bug? Perhaps it should be a separate bug blocked by this one. One could imagine it working well as collection point for all the more specific sub-issues required for good Gmail cooperation, including (but perhaps not limited to) this one. Certainly there are good reasons to want this bug fixed beyond just Gmail interoperability. I listed some of those when I first filed this bug in August 2001, two and a half years before Gmail existed. :-)
Created attachment 163301 [details] [review] proposed eds patch for evolution-data-server; Updated previous test patch to actual master, and also changed one thing, the deleted/junked messages aren't moved to real Trash/Junk immediately, but on folder sync (for example when you move to other folder). It's better because messages are moved in chunks and it doesn't block UI so often. I saw something similar in evolution-mapi. Oh, and to mention, this is for IMAP, not for IMAPx provider.
Created attachment 163303 [details] [review] proposed evo patch for evolution; Updated to actual master, and changed one thing, deleted messages can be shown in the real trash folder, same as those rally deleted will be checked out. I forgot to mention, deleted flag aha precedence from the junk flag, thus marking deleted message as junk will result in moving it to trash, not to junk folder. I tested both patches with my IMAP account and with GMail IMAP account, and it seems to work fine, messages can be deleted from the GMail account.
Review of attachment 163303 [details] [review]: Please commit the patch to master. ::: mail/em-account-editor.c @@ +2833,3 @@ + changed = TRUE; + } else { + e_notice (NULL, GTK_MESSAGE_ERROR, "%s", _("You cannot select folder from other account than this here.")); Please change this string to, "Please select a folder from the current account"
Review of attachment 163301 [details] [review]: Please make the change and commit the patches to master. Nice work!! ::: camel/providers/imap/camel-imap-folder.c @@ +2749,3 @@ + GPtrArray *uids, +imap_transfer_online (CamelFolder *source, +static gboolean maybe better to call imap_sync before imap_transfer_messages to get rid of the extra boolean can_call_sync.
Created commit 7162cd1 in eds master (2.31.4+) Created commit 3acb214 in evo master (2.31.4+) I'm not closing the bug yet, due to the request to do the same functionality for an IMAPx provider as well.
*** Bug 625032 has been marked as a duplicate of this bug. ***
+1 RoundCube and Thunderbird work the same. If you use Evolution at home, RoundCube webmail while on the road and Thunderbird (Windows) at work this option would be helpful.
(In reply to comment #103) > Created commit 7162cd1 in eds master (2.31.4+) > Created commit 3acb214 in evo master (2.31.4+) > > I'm not closing the bug yet, due to the request to do the same functionality > for an IMAPx provider as well. Is there any progress in porting this functionality to the IMAPx backend?
I just took a look at implementing this in IMAP+. I'm concerned that there seems to be a *lot* of this implemented in the back end itself. Conceptually, what we're doing here is something *other* than what the user asked for. When the user asks for "delete", we are just *moving* messages from one folder to another, instead. The back end already *had* a method for moving messages from one folder to another: the ->transfer_messages_to() operation. It would have been nice if we could have just *used* that function. Fundamentally, surely there's no need to modify the back ends at all? It would be useful if we could move this "delete actually means move" fakery up to a higher level, so that if a "real trash folder" is configured, the back end just sees calls to its ->transfer_messages_to() operation, and no mails are marked with the CAMEL_MESSAGE_DELETED flag. Then we wouldn't have to implement the same hack in every mail storage back end separately.
I'll take this into consideration for the new mail account format. Once we have a well-defined place to query this preference, the front-end can handle it all.
Note that changes in the provider will be always needed, because transfer doesn't expunge moved messages, it's not what IMAP would (or is doing in evolution right now) on its own.
I think the front-end can handle that part of it too. if real_trash_folder: transfer message to trash folder expunge source folder (or at least schedule it) else: flag message for deletion
This also implies that when using a real trash folder, you lose Undelete. That is unless we want to embed some kind of X-Evolution-Restore-To header with a folder ID prior to transfer.
That might be nice in the long term. Is it simple to implement? If it's complex, may I suggest that (since undeleting is probably an uncommon event) that undeleted messages just go back to the inbox of the account they're in? If you really want them moved to a particular folder in one shot, you can always explicitly move them from the trash to the target folder. I'd hate for this set of changes to common-case behavior to be held up by uncommon-case behavior that could be tracked and fixed later on.
(In reply to comment #111) > That is unless we want to embed some kind of X-Evolution-Restore-To header with > a folder ID prior to transfer. That's really hard. Messages in IMAP are immutable, so the only way to add such a header would be to create a *new* message, rather than copying the original. Which means all the data (and attachments) get read over the network and written back to the server... Surely this is an issue for "real trash folder" operation regardless of whether the hack is done in the back end or in the higher level? Once the message is moved, the message is moved....
If we can't easily track the original folder then I'm perfectly fine with "no Undelete for you!" if a real trash folder is used, rather than adding nasty hacks. I prefer the simplicity and elegance of a virtual trash folder anyway.
I agree with the people asking for this bug (and it really is a bug IMO) to be fixed. I am trying to move junk mail to the imap spam folder (the server runs sa-learn on it) as an interim step but came across another effect of the junk vfolder. Moving the mail messages from junk -> Spam (imap folder) causes the junk mails to be duplicated in the junk folder and nothing appearing in the Spam folder. After a few tries on a hunch I ssh into the server and checked the Spam folder. Sure enough there were several copies of the emails I had copied over. In short the issue is one of presentation to the user, a normal user will think the operation failed since all emails continue to appear in the junk folder (duplicated actually) and the Spam folder continues to appear empty. I thought you should be aware of this behavior since I doubt this is the experience Evo wishes end users to have. Hope this helps make Evo better for all. Thanks for the work so far.
On further discussion, it seems like all we really need the back end to offer is a way to "move these messages and expunge them from the original folder *immediately*". That could be done as an extra option to the existing transfer_messages_to_sync() function which already handles both copy and move operations (via a 'gboolean delete_originals' flag). The rest of the "when the user asks for deletion, actually move the message instead" behaviour could be implemented in the front end, just using transfer_messages_to_sync() on the back end with this new 'expunge immediately' flag. That way, we can support all mail stores without too much duplication of code.
Speaking as the guy who first posted this request, I think that the "expunge immediately" feature mentioned in comment #115 and comment #116 ought to be treated as a separate issue. It is not specific to treating Trash as a regular folder and deletions as moves into that folder. It is a space optimization applicable to any action that moves a message from one folder to another. But it's definitely not a hard prerequisite for *this* decade-old feature request.
+1 vote for this bug I'd like to remigrate back to Evolution as soon as this bug is fixed. In the meantime I'll continue using Sylpheed as it works fine there.
Do not add "me too" or "+1" comments to Bugzilla as they just create bugmail for everybody and don't add any technical value to the report. Thank you.
Hi, please excuse my "+1" comment above and please excuse this comment, too. Actually, I wanted to vote for this bug, but apparently this is not possible with Gnome Bugzilla. I know that there is no technical value adding a "+1" comment, but I think it is important that developers see that there are many people affected by this bug. Furthermore I do not understand why this bug has not been fixed as it was reported ten years ago and all important alternative mail programmes include this feature. Best regards
(In reply to comment #120) > Furthermore I do not understand why this bug has > not been fixed as it was reported ten years ago and all important alternative > mail programmes include this feature. You probably didn't notice from the above, but Evolution does support real Trash and Junk folders on the IMAP accounts, the only limitation is that this is done for IMAP provider, not for IMAP+. Edit your account settings and change Trash/Junk folder in the Defaults tab.
(In reply to comment #121) That's excellent! Please note that you have to restart Evolution after setting the Trash/Junk folders for the change to take effect.
Hope this is available in imap+ soon, tired of going to web browser to delete email from gmail account.
*** Bug 650444 has been marked as a duplicate of this bug. ***
*** Bug 517879 has been marked as a duplicate of this bug. ***
*** Bug 501476 has been marked as a duplicate of this bug. ***
I appear to have been using this feature with IMAP+ for some time. Can the bug be marked as resolved?
*** Bug 300351 has been marked as a duplicate of this bug. ***
*** Bug 481202 has been marked as a duplicate of this bug. ***
*** Bug 672222 has been marked as a duplicate of this bug. ***
Why resolved? I still can't assign trash or junk to my Gmail imap+ account with evolution 3.2
*** Bug 490505 has been marked as a duplicate of this bug. ***
*** Bug 681686 has been marked as a duplicate of this bug. ***
*** Bug 512012 has been marked as a duplicate of this bug. ***
Support has been added to IMAP+ for E-D-S 3.7.4. http://git.gnome.org/browse/evolution-data-server/commit/?id=1fd3da8927177ed0517abeaf3c7a29611d64546f Closing as FIXED.