This bug existed for a while before it disappeared some months (could be more than a year) ago, and now it's back. After starting my computer, which boots immediately into a KDE session, in maybe 20% of the cases I get dialogs from KMail/Akonadi asking me to pick an account for a filter rule. Currently I have two dialogs for the same filter rule, one on my work account, which moves messages marked as spam into a spam folder. There is no account listed to choose from. I have learned when this bug happened in the past that it's best to restart Akonadi, because even "Cancel" will just delete the filter rule. This might have changed (there were some commits to that effect), but I don't really want to risk it. Reproducible: Sometimes Steps to Reproduce: 1. Start computer with autologin 2. KDE session restore starts Akonadi and KMail 3. Dialogs asking for an account for filter rule(s) appear
Created attachment 81690 [details] Dialog asking for an account, with no accounts listed
Using my bugzilla rights to confirm my own bug :)
I just discovered about 200 new messages in my GMail inbox that were supposed to get filtered into different folders. This also happens sometimes when something is off in Akonadi. Not a big problem, I can just select all recent messages and "apply all filters". Maybe this information is helpful about the state of mail filters when the bug happens.
I also confirm this behaviour. In my case, the dialog is shown twice for the same filter, just one filter out of more than a dozen that I have. It targets the same filter each time. I also confirm that sometimes the filter is lost (read: deleted), but it's not clear to me in which conditions that happens. In such case, the targeted filter will change the next time. In my set up the startup of kmail happens automatically: I do not close kmail when logging out, and I have asked KDE to restore the previous session when logging on (it's just too convenient to give it up). Gentoo Linux Qt: 4.8.5 KDE Development Platform: 4.11.1 KMail: 4.11.1 Akonadi 1.10.2
same here: opensuse 13.1 with 4.11.2 Filter seems somewhat broken because sometimes all messages are put into trash and behavior is quite erratic. Sometimes no filter action takes place at all. Erasing filter does help for a day or two and then may reappear.
It might be a duplicate from https://bugs.kde.org/show_bug.cgi?id=321186 I fixed the problem yesterday. See details at: https://git.reviewboard.kde.org/r/112062/ With the title: wait until the akonadiserver is ready Write me about your experience. Thanks
Thanks Maurel for taking care of this, and sorry for taking so long to respond. I wanted to test your fix for a while, but not that long ;) I haven't seen this bug in a long time. Several months at least. If anyone still encounters this bug running master / trunk of the whole KDE & KDEPIM stack, please reopen.
Well... Dan found a problem with the fix, and made a revert. The bug might depend on the speed of the CPU. I now have a quickly CPU and no more problem! The bug doesn't appear again but isn't fixed.
I get sometimes the problem yet. KDE 4.13.3 on SUSE 13.1. Could this problem cause the delete any filter rules on ongoing mails? How quick should a CPU be to avoid it? My PC has a 4-core x 3.0 GHz. It is quick enough?
I also have this sometimes when I start Kontact. A dialog pops up and wants me to choose an account from an empty list. After that the filter is gone.
Oops, too fast: I'm running the 4.14 branch.
Running Kubuntu 14.10 and I'm still seeing this bug on both dual core and quad core computers. Didn't realise until this morning that when you dismiss the dialogue box that appears - and has no options other than ok and cancel - that filter is deleted.
Mark, I can confirm your experience. Since a couple of weeks this filter dialog box is appering almost every time on starting kontakt. KDE 4.14.3 on openSUSE 13.1 x64
I also confirm this bug. Gentoo Linux amd64 Qt: 5.5.1 Kontact 5.1.3 (KDEPIM 15.12.3) Akonadi 15.12.3 What additional info you need?
I confirm this bug for Leap 42.1 and both, the KDE4 version of Kmail 4.14.10 (Akonadi 4.14.10) as for the available Plasma 5 version with Qt:5.5.1 Kontact 15.12.3 and Akonadi 15.12.4 Both versions show the very same bug, an empty pop-up window claiming that the account for some filter rule is not found, you can click OK by choosing an empty line, sometimes this holds the filter rule alive, sometimes it vanishes. If you choose cancel, generally the filer rule vanishes. Sometimes even multiple filter vanish. Filters generally vanish one by one in chronological order of the filter list. What I discovered else, this but can be easily triggered by choosing not to apply a filter to multiple accounts (pop) if you have them but only to "one specific account". Especially if other filters are applied to all accounts indiscriminately (like pop-filters or spam and clamav filters). It appears the problem lies there somewhere. This is a very tedious bug, because on one hand constant and also sometimes hidden (no popup and you find out that some filter over the time vanish). I once had lost 50 % of all rules without warning. So this is valid for me for POP filtering and for both KDE4 version and Plasma 5 version of this programme.
I can confirm this problem for kmail/kontact 5.2.3 and akonadi 5.2.2 (currently in Debian testing). 1. The dialogs pop up when there is an automatic incoming mail filter set to filter only some of all available accounts. (In my case there are four IMAP accounts and I want to spam-filter two of them. I use bogofilter.) 2. The dialogs pop up *before* kmail or kontact are actually started, just after logging in. (Presumably when KDE starts akonadi?) 3. There is more than one dialog. (In my case there are two, presumably for the two checked IMAP accounts I want to filter.) 4. There is no workaround other than turning automatic filtering off and filtering manually. In particular, leaving the message boxes open and restarting akonadi, or leaving them open without doing anything doesn't work — no filtering gets done. 5. I cannot confirm that this is due to a slow CPU or old hardware. I have a fairly modern laptop (Intel i3-3110M @ 2.40GHz, 4GB RAM). I suggest to give the bug high priority. To me, a non-working spam filter is a show stopper for a mail client.
It still happens sometimes - for me, maybe on every 20th login.
Happens to me on every login. All my filters are lost and I have to add them again.
Can anybody still reproduce this? I've been looking around in the code, checking what it is supposed to happen... but I can't reproduce it right now, so it's difficult to see why things don't go like they're supposed to. I have some patches to add relevant debug output - if anybody who can reproduce it could run akonadi / mailcommon / kmail with these, that would be ideal.
Can reproduce every time here, with kontact Version 5.24.5 (23.08.5) shipped with openSUSE Leap 15.6 quit kmail akonadictl stop start kmail popup with Filter account is missing. Please select account to use with filter "um" Hit cancel and everything is fine. "um" is the name of a filter for an IMAP account. Here is its configuration: General> Filter criteria: Match all messages Filter actions: Move into folder: Local Folders/inbox Advanced> Apply this filter to incoming message: From selected account only: <the IMAP account> Apply this filter on manual filtering Add this filter to the Apply Filter menu Could it be that the corresponding akonadi_imap_resource is not started fast enough ? With `akonadictl start` prior to launching kmail, it's fine (no popup).
> Could it be that the corresponding akonadi_imap_resource is not started fast > enough ? > With `akonadictl start` prior to launching kmail, it's fine (no popup). Could be, but IIRC the data about "agents" (resources) is loaded from their desktop files when needed, so it shouldn't require them to be running. But my understanding could be incomplete - I am only reasonably sure about some of the data that it is loaded like that. It's good lead though that you can see this difference.
So yeah, the filters are loaded as soon as the Akonadi server reports that it's running. Or rather, as soon as Akonadi::ServerManager reports that the server is running, because there is no explicit interface for server status (which is IMO a problem). ServerManager reports the server as running if the server interface is present on DBus, the "updating interface" isn't (that one's OK, the updating interface is published before the main one so no race condition), and... ONE resource is running. That part is, well, basically, outright wrong. I don't see which client of the "running" API would be happy to consider the server as running if it has one out of n resources running, as opposed to none or all of them. The problems for fixing this are: - Determining which resources (agents) should be considered necessary for running status. Obviously broken ones (like agent binary not installed) shouldn't be, for example. This probably needs a status interface in the server because it's the only one that is supposed to have the information about the agents that *should* be running. (It could be derived from config files if all else fails, though.) - There should probably be a fallback to consider the server "running but with some broken resources", I'm thinking of 30-45 seconds. It would trigger for not obviously broken (see above) resources that still don't come up. That probably *will* cause bug reports from people who, for example, weren't using filters, so they would have been more or less OK before, but will have to deal with a now very slow starting KMail. Actually, after this thinking out loud session, KMail does know which agent IDs it wants to see, so I could create a somewhat quick and dirty fix to consider the server as running, for the purpose of filters, once these agents are present (with a timeout).
Draft merge request for KMail, any "compilers" here who can test it? I can't currently reproduce the bug myself. https://invent.kde.org/pim/kmail/-/merge_requests/162 There seems to be a similar problem (just starting akonadiserver brings up the dialogs) in, presumably, akonadi_mailfilteragent, mentioned in https://bugs.kde.org/show_bug.cgi?id=418293. That might need a similar fix, and at that point, a cleaner fix, or at least one in a shared repository, would make more sense.
(In reply to Andreas Hartmetz from comment #23) > Draft merge request for KMail, any "compilers" here who can test it? Couldn't compile here last time (https://bugs.kde.org/show_bug.cgi?id=420630); if still needed I can try again this week-end.
Here is the cleaner solution that I had in mind (note it doesn't need the other change). Akonadi does already wait until it has started all agents before reporting "ready", but started just seems to mean agent process or thread launched - which isn't that useful for clients who expect to see the agents on DBus. The fix assumes that that is the underlying problem and waits until all agents appear on DBus before reporting "server ready". Need to see if that assumption is correct. https://invent.kde.org/pim/akonadi/-/merge_requests/260
(In reply to Andreas Hartmetz from comment #25) > Here is the cleaner solution that I had in mind[...] > https://invent.kde.org/pim/akonadi/-/merge_requests/260 This one is merged now on account of it probably being sensible in any case, so we will see after the next release makes it to users if anyone can still reproduce this bug.