GNOME Bugzilla – Bug 207624
Mailer needs undo support for deleting / flagging messages
Last modified: 2021-05-19 11:46:16 UTC
Package: Evolution Priority: Normal Version: 0.12.99 Synopsis: Mailer needs undo support Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: I should be able to undo a delete operation. I use evo with deleted messages hidden, and an accidental delete (which happens somewhat often) means I have to go to the trash folder, wait for it to render, hunt down the message(s) and undelete. This also applies to move/copy, as well as to folder moving.
Yes please. I'm glad someone else thought of this :)
Yes this is needed before I go postal and kill everyone in my office building with an AK47. Every mailer on the planet has an undo...well except for maybe PINE. This is going to be needed for wide spread acceptance.
what would undo do? I think you are thinking of the composer which has undo support. Outlook doesn't seem to have an undo for anything but the composer (as far as mail parts are concerned anyway). Same with Mozilla.
Mozilla (and Netscape before that) have always had undo's in the mail component. For instance in Mozilla, I can move a message to another folder. I can then go to the menubar and click on Edit->Undo Move Message and watch the message as it reappears and is magically absent from the folder that I had just moved it to. Just like I would expect. Next I can delete this message. Then I can click on Edit->Undo Delete Message and watch the message also reappear in my folder, out of the trash. Mozilla (and Nescape before it) also have a Redo menu item for when you have done and Undo. I can go and click Edit->Redo Delete Message and watch as the message is again deleted from the folder and placed in the trash. So yes, the features requested in this bug do in fact exist in Mozilla. They also exist in Mail.app (Mac OS X) my current primary email client. I'm going to REOPEN this if no one minds.
I still this this is more trouble than it's worth to implement. what if someone expunges? are you supposed to be able to "undo" that? this is just way too complex to do with mail. but if you want it, feel free to implement it.
No, expunge is final. Thats why there is a dialog that says "This is final". I would go as far as to say this is a REQUIRED FEATURE. There is currently no way to undo a delete if you hide deleted messages, without first showing deleted messages, hunting down the one you just deleted, and undeleting it. Its even more annoying if you accidentally copy/move things to the wrong place. I'll fight with you in the office tomorrow about this... ;-)
So I'm curious what the outcome of your guys fight in the office was? Is this still a WONTFIX or not?
the outcome is: we accept patches :-)
Another strong vote of support for this feature. The main problem I have is that I use Ctrl-D to exit from ssh logins in my xterms. Sometimes I hit it one time too many and the xterm closes (as expected), and then my Evo window becomes active and my Ctrl-D turns into a "delete" operation. Just now I deleted a message at the bottom of my inbox, but I'm not sure what it was. I tried showing my deleted messages and since I had about 1500 come in today, most of which were deleted, my hopes of finding the one I nuked on accident are almost 0. Undo simply for the "Delete" operation would be absolutely wonderful.
"But now Red Hat, Sun and a Boston start-up called Ximian are advocating desktop Linux in some corporate environments." -- http://news.zdnet.co.uk/story/0,,t269-s2120806,00.html Not without an undo function!
The GNOME Human Interface Guidelines (1.0) state: "..Your application should therefore allow users to quickly undo the results of their actions.." See http://developer.gnome.org/projects/gup/hig/1.0/usabilityprinciples.ht ml I'd like to suggest the reopening this bug, since it breaks the guideline.
*** bug 251553 has been marked as a duplicate of this bug. ***
*** bug 233339 has been marked as a duplicate of this bug. ***
*** bug 251934 has been marked as a duplicate of this bug. ***
OK, so there's been no progress on this one for the last 4 1/2 years... ugh!? This is probably the single biggest annoyance to me with Evo (yes, there are many others, but at least some of the others got worked out with v2!), and it does make me wonder if I should jump over to t'bird which has this sort of basic functionality worked out.
I too would appreciate seeing undo support in the mail folder actions.
Sorry for the spam, but there's no other way to "vote" for a bug. This is very annoying. It's not as complicated as some of the other features that evolution has. Though evolution still doesn't have a sane delete system so I don't have my hopes up.
Since I've put my wife onto Evolution, this is one of the biggest complaints she has. This puts it high on my list to try and fix. I have no background in hacking Evolution, or GNOME in general, so I'm probably going to get in over my head. But I am a software engineer, so that's water I'm intimately familiar with. Has anyone made any forays into working on this yet? Has anyone gone through any design process thinking of potential solutions? If anyone has made any effort, I'd like to leverage, or at least learn from, their work. If nobody has looked at this in the last five and half years, then I'm on my own. Can someone point me at the documentation on what process a developer should follow if he wants to make a contribution to the Evolution project? Thanks, ~Jeff
there's been nothing done on this by anyone as far as I'm aware, so if you start working on this it'd be from ground zero. There's not really any documentation on the process of contributing to evolution. What you want to do is subscribe to the evolution-patches and evolution-hackers mailing lists on lists.gnome.org and then send proposals/design-ideas to the evolution-hackers list to get any feedback from the current maintainers (of which I am no longer, altho I still read the lists and if I have suggestions I'll voice them). Once you feel you have a plan, go ahead and start implementing. Once you've got a patch to submit, attach it to this bug report and send a copy of the patch to evolution-patches@lists.gnome.org for review. As far as documentation for the code itself, much of the code has gtk-doc style comments and there's some documentation on http://go-evolution.org Hopefully that helps
This bug is 5 years old! Web browsers use Ctrl+D to bookmark a page. Evolution uses it to delete a message. Get the wrong focus on the window, and you lose the message. Nice.
feel free to submit a patch that implements Undo?
Ah the standard reply. If I could write code C, I would do. But in all truth, the feature can't be needed that badly. There are only 21 comments on this bug, and it's five years old.
(In reply to comment #22) > Ah the standard reply. If I could write code C, I would do. > What about a bounty for donating money for - in my opinion - most basic things which a PIM should have. That would be great for non coders! > But in all truth, the feature can't be needed that badly. There are only 21 > comments on this bug, and it's five years old. > If that's way the priority which bugs are squashed is set, I will comment all bugs which I find and which prevend me from using Evolution! And I want to use Evolution because it's better integrated in Gnome than other mailing apps.
*** Bug 469126 has been marked as a duplicate of this bug. ***
*** Bug 570973 has been marked as a duplicate of this bug. ***
I used the equivalent feature in Thunderbird daily. I'm now trying out Evolution, and this is one of the big parity issues.
*** Bug 606973 has been marked as a duplicate of this bug. ***
Sometimes I delete a message incidentally and then cannot find it in the "Deleted" folder, because I do not remember message title. "Undo last operation" button should solve this problem.
I also agree to this initial thread, it should be an OOTB feature for all mailbox items regardless of which folder. Not all folders allow the delete button to delete items from mailbox folders, and undo should be available if the item is still available from another folder and not expunged. Can someone out there write a patch for this?
Yes please provide better Undo in evolution, accident happens :) Undo should be possible for: 1) recently Deleted mail 2) Recently moved mail 3) Recently Flaged spam 4) Recently Archived mail currently when i delete message, it will be striked for 5s , if i quick enough i can undelete it.. but thats too fast Thanks
This has been open for 15 years and is still getting fresh comments. It seems to be a feature people want. It is a feature that is available in every other mail client I've used in the past decade. Perhaps the current Evolution maintainers could prioritize it? I know, I know, "we accept patches." Well, look, the last time I worked on a C project was over a decade ago. I have a day job where I don't do software development. It would take me months of work just to brush up on my coding skills and get familiar with the current state of this project. It would take a regular maintainer much less time and effort to implement this. The follow-up argument: "how can you complain about the lack of a feature when you don't contribute to the project?" Well, I do. I make regular donations to Gnome Foundation (as well as Mozilla and TDF, whose products are vital to the success of Gnome). I report bugs when I see them. I expose new people to Free Software in general and Gnome Desktop in particular. Just because I don't submit patches doesn't mean I don't contribute. So, what will it take for a developer familiar with the Evolution project to implement this? I'm willing to increase my donation amount to The Foundation in exchange for having this completed - or just pay one of the maintainers a bounty directly. Honestly though, it's a feature that should already be there if Gnome is still serious about having a modern PIM as part of their desktop environment.
I am confused as to if I should file a new bug, it seems the "Edit -> Undelete Message" feature is unselectable even if I delete messages on IMAP / Gmail. Additionally, Ctrl-Z doesn't work either, It would add a lot of value to see these fixed / implemented as email is so critical to communication & our internet-dependent lives now.
Also willing to help contribute to a bounty for this.
I've been always wondering how this could work, because some changes have side effects, which are not that easy to undo. Imagine you've an IMAP account with real Junk folder set and you mark a message as just. When the change is going to be saved into the server, there also happens: 1. the spam filtering software (if any) is learnt with the spam message 2. the message is moved to the real Junk folder 3. if the server doesn't support MOVE extension, the message is deleted in the source folder 4. if the account has set also real Trash folder, then the message is moved to that Trash folder and then it is expunged from the original folder When moving to the real Trash/Junk folders there is not left anywhere an information where the message had been moved from. The above is an example of the move on the same server, but people move between accounts/servers too, which would be even more fun. Undoing such thing would be a problem, especially confusing the spam filtering software with a false spam (followed by a ham). I think some other software implements Undo of such actions by postponing when it actually saves the data to the server, maybe giving the "Undo" button offer in the interface for several seconds and once this offer is gone the operation is started/processed. That's not ideal, from my point of view, because the delay may not work for everyone, like I hardly realize I did a mistake within 5 to 10 seconds. Just my opinion.
Regarding SPAM filtering - if you move/flag a message into/as junk, then undo can only un-flag. As a best effort implementation I believe it should be good enough, and people who use this feature should understand what it means. Regarding the actual implementation - if Evolution can keep a local undo stack (like editors), and undo based on local information only, that should take care of most other issues Milan raised. I think no one expects to be able to undo an operation after the application was closed and then restarted. This will, of course, fail in the face of concurrent modification on two clients - but you can't solve all the world's problem in one application :-)
> I've been always wondering how this could work, because some changes have side effects, which are not that easy to undo. Same for me with Geary, tbh. :) The IMAP model doesn't make this stuff easy at all. :/ For simple actions like setting flag (read, unread, etc.), it should be pretty straight-forward: Just keep the mailbox name, the UID of the message and the nature of the change as state for undo, and apply the reverse to the same UID on undo. Right? For complex actions like moving/copying (and hence also trashing), IMHO server support for the UIDPLUS extension would likely needed for this to be handled in a robust way. With UIDPLUS, the UID of the message in the new mailbox will be reported by the IMAP COPY/MOVE command when it completes, and hence can be used to expunge/move back directly if the action is subsequently undone. The messages will likely get new UIDs in their new folders on undo, so the undo state for the action will need to get updated with the new UIDs. It is complicated a bit more in that the undo stack would need to get trimmed/cleared if the UIDVALIDITY of any mailbox mentioned on the stack is changed, since you can no longer trust the UIDs any more. There is on caveat though: It means that the order of the message in the original mailbox will change on undo, since undoing a move is just a second MOVE (or COPY+FLAG+EXPUNGE), not a "move to this folder in this location". This is a bit annoying, but without more support from the protocol the only way around would be to fake the message being removed from the source folder and just keep it hidden (i.e. never actually use MOVE and just "STORE \Deleted" on it instead, no EXPUNGE), so that as long as the original message is not expunged, then the deleted flag can just be removed when undoing the action. If it does get expunged, then just fallback to the less desirable behaviour. Undo for actions between servers can be handed in pretty much the same way, but just keep a note of the accounts involved as well as part of the undo state and use APPENDs instead of COPY/MOVE, right? > I think some other software implements Undo of such actions by postponing when it actually saves the data to the server, maybe giving the "Undo" button offer in the interface for several seconds and once this offer is gone the operation is started/processed. That's not ideal, Geary currently does this, and it is indeed a really bad idea. I'll be ripping it out as soon as I can.
This had been mentioned here as well: https://gitlab.gnome.org/GNOME/evolution/-/issues/1478 For the record, any such change will need a generic approach, not related to the provider; being it IMAP, EWS or other. The IMAP can be configured to use real Trash/Junk folder (the EWS has it so by default), which means the deletion of the message marks the flag and moves the message to the Trash folder as soon as the changes are synchronized to the server.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.