GNOME Bugzilla – Bug 223621
Add per-account mail Archive Folder option
Last modified: 2016-05-01 10:35:34 UTC
I suggest that a "Archive" local mail folder and "Archive" selection is added along with the existing options in the popup menu that is available in the message index: "Move to Folder" "Copy to Folder" "Delete" So if the user select "Archive", she should expect it to end up in a default local mail folder for saved messages (for example "Archive") or a user-defined folder (simular to the "Draft" and "Sent" folders). This functionality would make neophytes feel more comfortable.
What I would like to see even more than this would be to have Pine-like mailbox archiving. Set up a task to run every month ( or however often the user wants it ) to archive the selected mailboxes. Currently I have cron doing this job - which is fine for me but not for the non technical audience out there.
Workaround: You could use a filter, activated on a folder whenever you select Ctrl-A Ctrl-Y, to "move all mail older than 1 month ago to folder F," although it wouldn't necessarily sort it to individual folders. It'd be nice to have some sort of archive script, and shouldn't be that difficult to add: Add an item in the mailer prefs for Archiving, which chooses a directory (local or remote) and a date. Then, all the mail past that date will get periodically moved to the archive tree, which replicates the current-mail tree. Marking "Future" and changing OS to reflect that it's on all OS's.
*** bug 233704 has been marked as a duplicate of this bug. ***
Iffy dupe. My bug would have all folders compressed when not in use, but whatever - it also is a 'future, but wouldn't be too hard (given knowledge of codebase)' bug.
As directed by the hackers mailing list, adding my $.02 to this. I recall one clear detail from my OS courses. It costs many cpu cycles to read one block of data off of the hard drive. I do not know how many in todays ratios, but for the sake of argument, I think it is still a safe bet that to decompress and compress data is faster than to load uncompressed data off of a hard drive. That said, there stands to be some efficiency tradeoffs. I've used mutt for years now, with the compression option. It works, however it is more or less a hack. Before opening a file ending in '.gz' or '.bz2', mutt decompresses it to a temporary working directory, and then re-compresses it back when finished. This works ok, but when you have a single mbox file that is 480mb ending in .bz2, and a decompression time of many minutes on a fast cpu, you begin to realize there must be a better way. While I now understand (after reading the archival description above) the concept of archival, I have yet to understand how it would work for me. I want to view all emails from my wife, for example, and so long as the vfolder searches can also search the `archive' then whatever is implemented with this functionality in mind I am not going to complain. Personally, I see two feature requests in this bug id. One is archival, the other is compression. Both related, but distinctly separate. I personally would love to have an option per mailbox under preferences per mailbox to choose to compress the mailbox, and also a choice with regards to the compression mechanism. I do not know if it would make sense to compress mbox mailboxes, but perhaps if one understands that it would simply take a long time on larger mailboxes, then this could be accepable. I also do not know if it would make sense to compress Maildir mailboxes, given that the average email message is so small, adding a gzip header would add negligible space savings. For the same reason above, I do not know if it would make sense to compress individual email messages, either in a modified mbox file format (aka 'From ...' line unmodified, the rest compressed, or a special attachment type that is a compressed body), or in some other mannerism. It seems to me, that the best solution would be to invent a new mailbox format specifically with compression in mind. I would personally suggest such a format have a few user-tweakable knobs, with sane defaults: - groups of messages are compressed together, the groups are indexed, similar to zip format, as individual compression blocks, for `quick' retrieval in large mail boxes - the message groups could be defined as a threshold of a number of messages, or a size of messages; for example: every 100 messages is a group of messages in a single compression block -or- every time the 100k barrier is broken, a new group of messages would be started - the compression mechanism could be specified as: - bzip2 (1 .. 9) - gzip (1 .. 9) - compress - [any others?] - autoselect .. with `auto' each compression block would be tested with each available compression mechanism, to determine the one that compresses best; while it is true that one tends to be the winner in general, in some specific cases I've seen others better, and in some cases I've seen the compressed output of one pass is further compressable by a 2nd pass. Could anyone suggest anything that is wrong with the above thinking? My intention is to catch up to current development cvs HEAD, and see what I can do about the new mailbox format. P.S. One could also, with a new mailbox format, add a layer of encryption as an optional 2 pass `decompression' mechanism.
I think you're overcomplicating things. I also think you're wrong about reading a compressed file being faster, at least on today's hardware. I'd need to see a benchmark to believe that. imho, sticking with zlib is the way to go - no sense adding bunches of compression options, especially since most people will simply stick to gzip anyway. same goes for compression level. don't bother. just have a sensible default. so what the ui should come down to is something as simple as: [X] Compress or perhaps just: [X] Archive also, imho, only archive folders should be compressed. I'm not sure if they should be read-only or not tho, I wouldn't mind having the ability to removed messages/etc and/or append more - but for the most part, things shouldn't change - that's the whole point of making it an archive afterall. compresion definetely shouldn't be offered for non-Archive folders and I think Archive folders should be compressed. So as far as I'm concerned with this feature, Archive is the same as Compress :-)
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
I hate to add a "me too" on a feature request, but I require this feature in my current place of work. Given that I _rarely_ access older emails I don't care if the archive is compressed or not, only that it is local and frees up storage space on my IMAP/Exchange account. Would this be a Camel function? I'd like to dig a bit further to sort this out ASAP.
Hi there 2002, Here are my thoughts on this feature: * It could probably be a plugin. * When enabled, it would add a button with a configurable name. * It would have an associated configurable shortcut. * When activated, it would move selected messages into a folder. * It would be per account specific so that foo@example.com selected messages go to the foo@example.com/archive folder and that bar@example.com selected messages go to the bar@example.com/sort folder (or whichever were configured). * Bonus points if it lets you configure N different buttons per account. This would be particularly useful for users who commonly drag folders in to archives for example. I'd be willing to help out with this feature (although my C sucks) and/or help sponsor it financially, although I don't have a lot of funds to contribute. Cheers
PS: This could also fill the equivalent of the gmail "archive" button, which in equivalent evolution terms is the same as "moving" a message from any folder to the "All Mail" folder. (This causes a duplicate, which ultimately gmail translates into an "archive" operation)
Let's do the usual "Archive Folder" option, which means a per-account setting to select the expected Archive folder, then an option in popup or menu Messages->Archive... to move selected messages into the setup folder. No compression, nothing like that (how would you do that with remote accounts anyway). As the On This Computer doesn't have account properties then the settings can be found at Edit->Preferences->Mail Preferences->General tab->Archive Mail section. An issue with virtual folders, when multiple accounts can be selected uses a quick check for the desired account by picking the first selected message and for it the account of the source folder (no recursion involved) to enable/disable the menu option, but in the execution of the action it checks whole selection and if there are set messages from multiple accounts then nothing happens. This is for performance reasons. The default shortcut is Ctrl+Shift+A. There had been needed changes in both evolution-data-server and evolution. No way for 3.12 due to new translated strings added, though it's the only limitation, the patches as such should work fine there, maybe only with a little backporting foo). The changes are: Created commit 0914aa0 in eds master (3.13.7+) [1] Created commit f6c0c82 in evo master (3.13.7+) [2] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=0914aa0 [2] https://git.gnome.org/browse/evolution/commit/?id=f6c0c82
(In reply to comment #11) > Let's do the usual "Archive Folder" option, which means a per-account setting > to select the expected Archive folder, then an option in popup or menu > Messages->Archive... to move selected messages into the setup folder. No > compression, nothing like that (how would you do that with remote accounts > anyway). As the On This Computer doesn't have account properties then the > settings can be found at Edit->Preferences->Mail Preferences->General > tab->Archive Mail section. An issue with virtual folders, when multiple > accounts can be selected uses a quick check for the desired account by picking > the first selected message and for it the account of the source folder (no > recursion involved) to enable/disable the menu option, but in the execution of > the action it checks whole selection and if there are set messages from > multiple accounts then nothing happens. This is for performance reasons. The > default shortcut is Ctrl+Shift+A. > > There had been needed changes in both evolution-data-server and evolution. No > way for 3.12 due to new translated strings added, though it's the only > limitation, the patches as such should work fine there, maybe only with a > little backporting foo). The changes are: > > Created commit 0914aa0 in eds master (3.13.7+) [1] > Created commit f6c0c82 in evo master (3.13.7+) [2] > > [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=0914aa0 > [2] https://git.gnome.org/browse/evolution/commit/?id=f6c0c82 Very sweet... Looking forward to trying this somehow!
Tried this out with GNOME continuous... ( http://build.gnome.org/#/ ) Using gnome-continuous-x86_64-devel-debug-20141021.17.qcow2.gz Some issues: 1) Control-Shift-A is also used by "Create new appointment" and so it doesn't work. I'd recommend Control-Alt-a instead for this archive feature. 2) Even after selecting a message, the archive option still appeared "grayed out" and I wasnt' able to click on it. So it actually doesn't work! ... But I busted out gtk-inspector, and after trying to figure out how it works, I finally found the menu item you added... I found out that the grayed out means "sensitive" property, changed that to True, and was then able to click on it! Unfortunately, it did not move my message. So it still doesn't actually work :( 3) There should be a corresponding menu item on right click for this archive action. There are the corresponding move to folder, and copy to folder. Archive is missing from the right click menu, but not the main Message menu. Thanks for looking into this, hopefully you can test it, fix issues, and let's get this into Fedora 21!
Actually... A follow up RE: #2... I think this might have been my fault with an account issue... If I added the Main account (On this computer) archive option this worked as intended. So actually, only #1 and #3 look to be issues.
(In reply to comment #14) > Actually... A follow up RE: #2... I think this might have been my fault with an > account issue... If I added the Main account (On this computer) archive option > this worked as intended. So actually, only #1 and #3 look to be issues. Right, there is only one reason when the option can be insensitive, it's when the account to which the folder belongs doesn't have configured the Archive folder.
(In reply to comment #13) > Tried this out with GNOME continuous... > > ( http://build.gnome.org/#/ ) > > Using gnome-continuous-x86_64-devel-debug-20141021.17.qcow2.gz > > Some issues: > > 1) Control-Shift-A is also used by "Create new appointment" and so it doesn't > work. I'd recommend Control-Alt-a instead for this archive feature. Ouch, I overlooked that. I changed the shortcut to Ctrl+Alt+A and removed an icon for this item, because it was quite similar to the other two there: https://git.gnome.org/browse/evolution/commit/?id=ba3c08c > 3) There should be a corresponding menu item on right click for this archive > action. There are the corresponding move to folder, and copy to folder. Archive > is missing from the right click menu, but not the main Message menu. I cannot reproduce this for accounts which have set an Archive folder. If the account doesn't have it set, then the menu item is insensitive and thus hidden from the context menu.