GNOME Bugzilla – Bug 211353
assigning categories to emails
Last modified: 2013-09-13 00:54:19 UTC
It should be possible to assign categories to email messages like it can be done with appointments / tasks and contacts, so one can sort emails by applying Filter / vFolder rules using those categories.
*** bug 238333 has been marked as a duplicate of this bug. ***
still missing in 2.1.4, what about colors and labels? to me this gets to overloaded, would be pleased to see a fusion of colors and labels in 2.4/2.6 to solve this... any comments? :-/
*** bug 218120 has been marked as a duplicate of this bug. ***
I think it would be very interesting to have the posibility of adding new labels/colors to the ones defined by default in evolution
Created attachment 89999 [details] [review] EDS
Created attachment 90000 [details] [review] Evo
A patch that I made to bring in custom labels support. Ability to add new labels, apply them, sync up with the IMAP server were working. Search and Quick-show code needed some change as labels implementation here does not use MessageTags but CamelMessageFlags. Needs some more minor tweaks before getting into SVN.
Off to you Milan now.
just noting here some details I found while reading the patch and talking to Sankar about this feature : * could use some glib functions (g_list_foreach in place of a loop on the list) * the graphical part will probably need some rework because as Sankar told me it still uses the same way to present the information which will inevitably disallow some users to put as much labels as they'd want to. I think it needs a treeview. iirc Sankar told on the channel (months ago) that it couldn't go in 2.12 because something wasn't as good as it ought to be in the eds part. I'll let him expose the details.
Created attachment 100942 [details] [review] proposed eds patch for evolution-data-server; I dropped last storing into imap into user_tag and flags and did storing only into user_flags. It has a disadvantage, if server doesn't support it, then it will be very unhappy, as kjetilho told me. Otherwise the label names are always "$LabelX", where 'X' is a number of that label, but locally first 5 labels are renamed, only because of simplicity of filters/search folders expressions and backward compatibility. Anyway, I think the old filters/search folders should be re-setup, I'm not sure about migration of this part. Also, users cannot change used label tags. It will be always in "$LabelX" form. It has the advantage when you move to other Evolution, and have IMAP account, then you can show the column of labels and see there also labels which you do not have setup (yet).
Created attachment 100944 [details] [review] proposed evo patch for evolution; Also the format of Labels in gconf key has been changed, so the "go one step back" is a bit harder - it doesn't work properly. Which is no surprise, I guess. Those changes in GConf made my Glade2 editor. I hope it will not break anything there. I dropped also a part with "new label" popup-menu item, which Sankar had there, because it had one big disadvantage, when changing this and with Preferences window opened, one need to sync changes there to preferences window, which is very ugly, because you cannot relay on changes of gconf key, because the preferences dialog itself stores there, and it's not necessary to rebuild tree when it own changes key. It was easier (and cleaner) to not add there such menu option, than dealing with flags or registering/unregistering key change listeners or something. Anyway, can be improved later, if you really want it.
Jeff, can you look at the camel part too, please? Thanks in advance.
Known issues: a) if server doesn't support user flags, then bad luck. Same as Thunderbird. b) Add "New Label" menu item to popup menu with labels as Sankar had. c) Show filter uses labels too, it isn't updated properly (at all). d) Creating new labels is setting tag for the first empty position, which means when you have 5 system labels, and you add 2 labels and then delete the sixth, then you have there $Label1-5 and $Label7. The next "Add" will create label $Label6, which is probably wrong. The other issue is that on the other machine, you will have 6 labels, same as on this before adding new, and it will not match, you will need to add two labels to have it same, even the first one evolution has only 6 labels visually. e) hide tag column in labels - maybe make it configurable, because of issue in d)
Created attachment 100978 [details] [review] proposed evo patch ][ for evolution; fixes ball c) and e) in comment above. (Please notice changes in widgets/misc too). Btw, the c) didn't work before too. Somewhere is a bug about "Evo does not remember last label selected in search filter after restart". This is fixed with this patch too, as side-effect. NOTE2: When you will commit eds patch, there has been added some "FIXME" notes, please, remove them. I think they are false, it was copied from initial Sankar work. Thanks.
This patch is committed for 2.21.4 (Note: I haven't removed any fixmes. I want you to check and do it :) Please list any bugs/known issues here so that we can take this to completion from here.
I have reverted the fixes in filter/. It causes cyclic dependency. (mail_config_get_labels)
Created attachment 101095 [details] [review] Reverted filters/ patch
(In reply to comment #13) > Known issues: > > > c) Show filter uses labels too, it isn't updated properly (at all). Yeah. I never Implemented this. You also have to update general filters code as well. Also, we should write some migration code which will convert all Tags to Flags or better make filters and quick-show work with both $Label1-5 tags and flags then-after to maintain backward-compatibility. That way if u switch to an old version you can still retain labels. > > d) Creating new labels is setting tag for the first empty position, which means > when you have 5 system labels, and you add 2 labels and then delete the sixth, > then you have there $Label1-5 and $Label7. The next "Add" will create label > $Label6, which is probably wrong. The other issue is that on the other machine, > you will have 6 labels, same as on this before adding new, and it will not > match, you will need to add two labels to have it same, even the first one > evolution has only 6 labels visually. First 5 flags should be stored $Label1-5 and then on we should use the Label name as the Flag name. If the label name contains space or anything special, we have to encode it. Camel has a function for this, or I was writing one. We need to store our labels in this way, because, only then, the labels that you create will be consistent across all clients, say Thunderbird. (Much like the same reason why we chose $Label1-5) > > e) hide tag column in labels - maybe make it configurable, because of issue in I remember doing that. Havent I ? May be.
Created attachment 101138 [details] [review] proposed evo patch ]I[ for evolution; This was really though. User label names are now tagged as in Thunderbird, based on the tag name. It has all disadvantages as there. Editing in Preferences has been changed and the popup menu option "New Label" added. Still need to fix filter-label, which is the last thing to do, if I see correctly.
Sankar, would you review and approve this?
Filed bug #504210 before I saw this - set label in filter does not work in 2.21.4. Am I reading the above correctly that this is known and should be discussed here? If so, that is a dup of this bug. Thanks for working on this, BTW.
Hi Mikael, yes, you've right, it should be fixed and is part of this bug and I plan to look at it today.
bug #236352 is partly solved by this.
*** Bug 504210 has been marked as a duplicate of this bug. ***
Created attachment 101211 [details] [review] proposed evo patch IV for evolution; Here's a final patch (I hope) to close this bug. It addresses same things as the patch above, but here are added things about filters and fixed tab name in preferences, as srag noted to me. It seems to me like working, even the part for filters looks very nasty (notice that even you can attach notification for the gconf key change to client, then it doesn't worth it because the cache is/can be updated later than the functions. Based on my experience, they prepend functions to the list, so even the function for recreate cache is registered first, it's called last, which is wrong).
Created attachment 102004 [details] [review] evo sorting patch for evolution; this is independent patch from the previous one, I didn't notice the normalized columns at the end, so the label column made there a bit mess. This fixes it.
I did some testing with the patches. With this patch we use $Label5, $Label6, etc. to store labels on the server rather just using the Label name. IMO, this can be avoided and just label name can be used as the FLAG names. So that we get consistency of labels across Thunderbird and other clients. And in future, we might have "Qeury-for-label = <label>" support in the servers in which case, saving the label name instead of $Labeli will be beneficial. Patch looks good otherwise. Okay to commit. Decision on the flag name to be used cannot be made by me. Srini/Milan: Decide on that front. Thanks.
I am not sure if I explained that "query-for-label" part correctly. The use-case is like: -> Using Sieve rules on your server, user set up rules to mark any mails from his boss (or sponsors) to be marked important. -> user goes for a tour where he can browse via his mobile IMAP client on a slow band-width connection. -> Instead of querying for all mails in a folder, he queries based on labels (say Important mails alone) . May be futuristic. May be already support exists for such conditional access. IIRC, Mails with specific labels for GMAIL can be accessed via atom etc.
Milan, Wasn't the conclusion on the last discussion on the chat was to use the label names to store than the $LabelFoo? I feel that Sankar has a valid point. Also it helps users who switch clients/different instances of Evolution. I would suggest to go back to that and commit.
I was wrong. I missed out the e-util-label.c part in my svn diff. And I have created some labels already before applying the patch and hence they were synced as $Labeli instead of label-name. Sorry for the noise. Patch works fine. I might suggest for some more testing of the silent/set operation on different IMAP servers for these flags. Patch looks good to commit. Please go ahead and commit.
Committed to trunk. Committed revision 34788. I joined both last patches (patch IV and sort fix) into one commit.
I trying 2.21.90 now. I can set labels manually, but I can't seem to get the Set Label filter action to work - no label is set. Is this supposed to work? If this is supposed to work, this bug has to be reopened. To repeat: Create filter rule, use action Set Label to some label. apply filter to a matching message Watch the action not being applied.
It is supposed to work. Thanks for pointing this out.
Created attachment 104109 [details] [review] proposed eds patch ][ for evolution-data-server; I hoped we can skip this, but it shows up that such thing is necessary to let it work. I do not like this way, but because same is used in search folders and filters, then there is no other way than this.
Milan, commit it to trunk,
Committed to trunk. Committed revision 8449.
Confirmed fixed in latest Ubuntu Hardy version (2.21.91-0ubuntu1)