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 223621 - Add per-account mail Archive Folder option
Add per-account mail Archive Folder option
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.4.x (obsolete)
Other All
: Low enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 233704 (view as bug list)
Depends on: 483689
Blocks:
 
 
Reported: 2002-04-18 12:25 UTC by Ole Aamot
Modified: 2016-05-01 10:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ole Aamot 2002-04-18 12:25:15 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.
Comment 1 corvi42 2002-05-09 19:53:35 UTC
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.
Comment 2 aaron 2002-10-21 17:10:55 UTC
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. 
Comment 3 Gerardo Marin 2002-11-12 20:21:14 UTC
*** bug 233704 has been marked as a duplicate of this bug. ***
Comment 4 Jeremy Browne 2002-11-12 20:49:10 UTC
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.
Comment 5 Todd T. Fries 2004-05-04 17:46:16 UTC
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. 
Comment 6 Jeffrey Stedfast 2004-05-06 21:32:14 UTC
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 :-)
Comment 7 Calum Benson 2005-07-28 10:39:45 UTC
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
Comment 8 Aidan Delaney 2005-10-18 15:00:13 UTC
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.
Comment 9 James 2013-06-26 17:26:14 UTC
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
Comment 10 James 2013-06-26 17:27:34 UTC
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)
Comment 11 Milan Crha 2014-10-20 13:19:10 UTC
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
Comment 12 James 2014-10-20 16:52:58 UTC
(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!
Comment 13 James 2014-10-22 08:55:35 UTC
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!
Comment 14 James 2014-10-22 09:03:11 UTC
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.
Comment 15 Milan Crha 2014-10-22 10:30:48 UTC
(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.
Comment 16 Milan Crha 2014-10-22 10:48:36 UTC
(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.