GNOME Bugzilla – Bug 263236
It's unclear that deleting from a vFolder actually deletes email from other folders
Last modified: 2013-09-13 00:58:34 UTC
Description of Problem: Deleting mail from a vFolder does not warn you that it will actually delete the mail from your inbox or other folder in addition to the vFolder Steps to reproduce the problem: 1. Click on a vfolder like Unmatched. 2. Select an email and delete it. Actual Results: No warning message. Go to inbox or other folder and the mail is gone forever, no undo either. A good warning message would be "Warning deleting email from a vFolder will delete the actual email from one of your inbox folders. Do you really want to do this?" Expected Results: Email removed from vFolder but still remains in inbox How often does this happen? Every time. Additional Information: While the vFolder documentation clearly indicates how vFolders work, when you eventually find it, it doesn't say anything in the glossary. Thus after reading the glossary I thought that vFolders were COPIES of mail in other folders and when I deleted everything in unmatched because I didn't care about it, All my email was gone in Inbox. OS Fedora Core 2
adding "vfolders" keyword
changing component to "Mailer" to get rid of the UI component, also reassigning as discussed with nags... adding UI keyword.
The mentioned warning dialog would be a safe way to remind the user and prevent data loss. Agreed here, I think. Of course, this one needs a checkbox to never see it again. Anyway, the "Expected Result" is just plain wrong. This is obvious from your own Additional Information. The expected result is the way it is meant to work, the way it is explained in the docs. This is a "search", so the expected result is to remove the mail.
This certainly needs something done about it. Right now behaviour is incosistent with no explanation for users: if I delete a vFolder, it deletes the folder but not the emails in it, but if I delete an email in a vFolder it is deleted. Though this is correct - according to the fact that the vFolder is a search not a folder, whereas the email IS an email - this should be made clearer to users.
Created attachment 97120 [details] [review] proposed evo patch for evolution;
Milan, Nice. But I think we should have 'Don't ask this again' sort of check box also. Otherwise it could be annoying.
Are you sure, srini? In this particular case, it is better to annoy them, because of keep data, I think. But probably I'm wrong. What do you think?
Milan, users may not know this, so it is fine to popup for the first time. If the user knows that well and it does that repeatedly is what is annoying. So for them, 'Dont ask me again' will help.
Created attachment 98653 [details] [review] proposed evo patch ][ for evolution; here we go, new key for that is "/apps/evolution/mail/prompts/delete_in_vfolder".
Looks fine to me. Test and commit.
Committed to trunk. Committed revision 34523.
NO. #: ../mail/mail.error.xml.h:46 "Delete messages in virtual folder?" #: ../mail/mail.error.xml.h:45 "Delete messages in virtual folder "{0}"?" #: ../mail/mail.error.xml.h:125 "Warning deleting email from a virtual folder will delete the actual email from one of your Inbox folders.\n Do you really want to do this?" "Warning deleting email" contains two errors. it should be "Warning:" and either "emails" or "mail" (and corresponding to the second "email" string. and we don't have "virtual folders", we call it "Search folder" EVERYWHERE else? how much do we want to confuse the user? and it is NOT in Inbox folders! i have search folders on non-inbox folders too!
Created attachment 99020 [details] [review] proposed evo patch ]I[ for evolution; ok, ok, I'm not good in writing texts, you know. This is better, I hope :)
1) keep "Delete messages" i would say. 2) "Deleting message from a Search Folder will delete the actual message from one of your local or remote folder." "deleting message" does not work, must be "messageS". also "one of your local or remote folderS".
Created attachment 99025 [details] [review] proposed evo patch IV for evolution; Maybe better now?
yepp.
Committed to trunk. Committed revision 34529.
My fault that the checkbox is not saved properly, so fix for this is here...
Created attachment 100381 [details] [review] proposed evo patch for evolution; I tested it wrong. The check is hidden in gtk_alignment, so the function didn't find it properly, so didn't save the state. Fixed here.
didn't test it. but looks good to me. Test and commit.
Committed to trunk. Committed revision 34660. I'm sorry for such obvious thing... huh...