GNOME Bugzilla – Bug 556116
unmatched search folder missing in 2.24
Last modified: 2009-12-04 12:35:12 UTC
unmatched search folder is missing after upgrade from 2.22 to 2.24 Distribution: Mandriva Linux release 2009.0 (Official) for i586 Gnome Release: 2.24.0 2008-09-23 (Mandriva) BugBuddy Version: 2.24.0
*** Bug 556117 has been marked as a duplicate of this bug. ***
Dan, yes. With disk summary, its not implemented.
I don't know what "Disk Summary" is. Using un-matched was a very effective way to manage mail (all low-importance mail goes into search folders. Everything left behind (unmatched) is therefore important.) How can I turn it back on if I am using evolution-exchange as the backend?
Same problem. I've upgraded to Ubuntu 8.10 and the unmatch folder dissapear. There's any way to turn it back? (I've looked in the menues, but nothing seems to activate it).
Its not implemented, in the new model. May be next release or so, I might get time to implement it.
Do you think is possible to re-implement temporary as a external plugin? I'm willing to help to implement it. Is possible to write it in python? Luca
It isn't possible to do as a plugin. It should be done on the core code.
uhm, this is not a good news :( I underrstand your needed to disable it cause the huge work to rewrite model, but I think to wait next release is too much time. I, and a lot of people too, use evolution because it has a great virtual folder system, which work on different account, on different protocols. I think without unmatched folder evolution is like any other mail client... If you can re-implement it before next gnome release you may convince a lot of users to stay with evolution...imho
Luca, Lemme see, my work load is pretty high, and I can't commit. But, this is something very much the next big thing to do for me. [this and vfolder of vfolders]
Is not possible to use the "expression" options in search folders? I searched in the website to learn how to write an expression...but I didn't find any.
I agree this is a very important feature that was lost. How difficult do you expect spinning up a developer for this would be? Are the disk summary or new model (not really sure what that means) changes and design documented somewhere?
I just upgraded to Fedora 10 (Evolution 2.24.1), and I fell in love with the search folders feature. The Unmatched folder was very important in knowing what was "left", and thus needed to be looked at, as well. So, chalk another vote up to the importance of re-implementing the unmatched folder. I realize you're already pushed as it is, but I just had to leave a comment on here once I discovered the feature was missing in the new version of Evolution.
Guys, I promise, I would get it back, just a matter of time, I would say.
Not trying to put any more pressure or anything but this sole feature is THE reason why I've been moving family and friends to Evolution in the past year. I've been away from Evolution for different reasons for a while but when I was moving all my mail from TB to Evo this morning I discovered this with horror!!! I hope this doesn't mean we'll live without Unmatched search folder for months... :-(
*** Bug 559185 has been marked as a duplicate of this bug. ***
This is one more vote for getting the 'unmatched' vfolder back as soon as possible.
Like others, this feature was a critical feature for me. I didn't found how to vote (maybe I am not allowed to as an "anonymous" ?) but I vote for it ! And, Thanks guys, for this wonderfull mail client ;-).
I was hoping the feature was back into 2.26 but it's not. Now this is not serious. Evolution is supposed to be business grade sofware, right? An application a business can rely on. How on earth has this essential feature be gone for so many months now and it isn't back on next (2.26) release? How are business supposed to trust this app and the team behind it? Sorry but I'm VERY angry at this.
Patches are always welcome - ranting doesn't get things magically fixed. And manpower and ressources are very limited currently, hence also priorities.
I've a question about it, is not possible to use "Expression" field in search folder (i read is possible to define complexed expression) to obtain a quick and dirty filter? I'm using a dirty search folder, called inboxes, which has several "Mailing list" desn't contain "xyz" rules and the "match all" options choosen. Any other/better ideas?
I took a cursory look at this. The trouble is that the backend is written using something called Camel. To no surprise, it appears Camel is completely undocumented. It would be helpful if someone could point to something that describes how Camel works.
http://library.gnome.org/devel/camel/stable/
@André Klapper: I hope you don't mean "just fix it yourself or shut up". If Evolution is just a hobby project, please let us all know. Businesses need to trust their tools. If Novell is not serious enough about a business e-mail client we should know. I can understand an essential feature gets removed temporarily due to architecture changes (especially if the devs warned everyone of the issue and provided easy ways to keep the old version while updating the rest of the desktop, which they haven't...). But I do not understand that the feature remains removed for two consecutive versions with no expectations about its come back. Can we at least have an official statement from the developers about this feature being brought back and when? Again: businesses have to make decisions and if we must move from Evolution to other mail platforms we'll do. I just need to know how serious this project is about business needs. Not only for myself but for my customers too.
(In reply to comment #23) > @André Klapper: I hope you don't mean "just fix it yourself or shut up". I meant what I said. "me too" comments here will not motivate a single person to work on this, instead it's demotivating for developers. Don't ask me why it is like that, but I've seen this several times in the last years - trust me. > If Novell is not serious enough about a business e-mail client we should know. Please contact Novell by using the contact info written on your Novell support contract. They might also offer you Groupwise if you are interested in Novell products. But this here is still GNOME.
I understand Evolution is sponsored by Novell. If it's not and it's effectively a hobby project, please let me know. If Evolution is not intended for businesses, also please let us know. If expressing dissatisfaction is inappropriate here or this is the kind of project where developers don't care about users satisfaction at all, also please let us know. However, if Evolution developers care about business users satisfaction and some company is pouring money into its development, I believe my points are perfectly understandable and hopefully someone will take responsibility for this issue ASAP.
Is there any chance of getting developer hints on this? For example, Camel already has explicit provisions to support the unmatched search folder. Is this in fact complete, or does Camel need further work? Are there other changes on the data server side that need to be made? Or is it sufficient to make changes on the plain evolution side? As for Camel documentation, this actually contains more than is in the source code: http://www.go-evolution.org/Camel @Aleve: I'm not a developer, so please don't take my comments as official. 1) Evolution, like most other open source projects, is offered "as is". 2) I don't think Evolution does distinguishes between users, business or other. 3) As Andre noted, this is the GNOME bugzilla, not Novell's site. I don't know whether Novell actively supports Evolution, but if they do, they clearly aren't sufficiently motivated to fix this.
FWIW, I'm on the verge of getting this done, unfortunately Im on leave for the week, so wait. Aleve: I'm the maintainer of the project. Evolution is on a transformation, to be usable on low-memory/mobile/netbook devices also. For these progresses, the *most* required thing was the *disk-summary* changes that was done during GNOME 2.24. I solely accecpt Evolution 2.24 wasn't up to the mark. But by 2.24.5 I made sure, except vfolder's regressions & maildir issues everything else was solved. GNOME 2.24.5 was release ~2-3 weeks before the actual 2.26.0 code freeze. So Effectively I would consider that 2.26.0 is a stable release for 2.24.0. We are approaching GNOME 3.0 very soon, and we have quite a few plans for that. This recession added to our problems and we have a *very* small team that works fulltime on the project. So now we really have to prioritize our efforts, carefully. Not saying that these regressions aren't important, but given the things in hand, it is taking longer than normal, which I have to agree. I hope I had clarified you, and continue with us, it will all be solved soon. Thanks. Btw, I really liked the way you approached & asked and felt that I should explain. I really hate about the other rants, few guys do on every bug :/ which hardly helps me to look at the bug again.
Created attachment 132350 [details] [review] Enable unmatched I had reviewed most of the code, and I saw that it should be fine now. This patch adds back Unmatched vfolder. If any of you building from code, can you play with this patch. and see if the unmatched vfolder works fine. If all is fine, I can push this soon to the build.
Johnny, committed this to 2.26.1 build, on my behalf.
Dear Srinivasa: thank you very much for your explanations and your rapid response. Please let us know when a binary is available for download.
(In reply to comment #29) > Johnny, committed this to 2.26.1 build, on my behalf. > I agree with that : i built against 2.26 (data-server and evolution), and after data import from 2.24, i feared some problems( index update, freeze during search, incomplete search results(!??!) ). But after a few days use and restarts, everything began to go like a charm : no freeze or crash, no data loss for me and no index or search weirdness. Thanks a lot Srinivasa.
(In reply to comment #30) > Please let us know when a binary is available for download. See http://live.gnome.org/TwoPointTwentyseven for the schedule. Please ask your distribution for providing updated packages once 2.26.1 is available.
(In reply to comment #29) > Johnny, committed this to 2.26.1 build, on my behalf. > Too bad it doesn't seem to be in 2.26.1. I patched it and everything is ok again. So, i wonder whether some late trouble arose with the patch or whether it's just been commited too late. I'd like to propose it for Mandriva 2009.1 Final due later this month, but how to know if the patch has been rejected or something?
(In reply to comment #33) > (In reply to comment #29) > > Johnny, committed this to 2.26.1 build, on my behalf. > > > > Too bad it doesn't seem to be in 2.26.1. Sorry I missed this for 2.26.1. SCM madness.
(In reply to comment #28) > Created an attachment (id=132350) [edit] > Enable unmatched > > I had reviewed most of the code, and I saw that it should be fine now. This > patch adds back Unmatched vfolder. If any of you building from code, can you > play with this patch. and see if the unmatched vfolder works fine. If all is > fine, I can push this soon to the build. > Uuuh, wait. There are several problems for me. It was sometimes an mess until i deleted .evolution/mail/vfolder and restarted evolution-data-server. Now i can see clearer. Mail arrived before a .evolution/mail/vfolder deletion is correctly sorted, unread counts ok. (after deletion and e-data-server restart, am i clear?) When new mail arrives, it's not always dispatched in vfolders, but sometimes stays stucked in unmatched vfolder. In this case, unread messages counters are wrong. Click, vfolder navigation, context menu refresh, etc... don't help. After evolution-data-server restart, nothing better, and even some previously correctly sorted mail (arrived after .evo.../vfolder deletion) goes back to unmatched vfolder. When i click in unmatched vfolder a message that should be in a different vfolder, evolution crashes or just doesn't display anything. The only way to get inbox correctly sorted is 'evolution --force-shutdown' , 'rm -rf .evolution/mail/vfolder' and restart evolution. I hope this will help. I use patched 2.26.1 evo-data-server and mandriva rpm rebuilt by myself evolution 2.26.1
(In reply to comment #34) > > Too bad it doesn't seem to be in 2.26.1. > > Sorry I missed this for 2.26.1. SCM madness. > Pushed 2.26.1.1 with this patch.
I think Unmatched folder has a wrong behaviour because it count also inside junk folder. If you try to add some email in your junk folder, and they don't match any rule (so they should finish in your unmatched folder) you have a wrongly count email number.
Does anyone check about my last comment (#37)? Thanks
(In reply to comment #37) > I think Unmatched folder has a wrong behaviour because it count also inside > junk folder. > > If you try to add some email in your junk folder, and they don't match any rule > (so they should finish in your unmatched folder) you have a wrongly count email > number. This can be taken care in separate bug. Shall we close the bug as original bug has been fixed ?
Ok for me, but please, don't wait other 3 months to do it ;-) Thanks again Luca