When an email is moved from inbox to another folder, it re-appears in inbox ( the copy in the other folder stays there btw ). Reproducible: Always Steps to Reproduce: 1. receive an email 2. move it from inbox to another folder 3. verify that the email has been moved to the other folder 4. go back to the inbox 5. the moved email appears again in the inbox This behavior is the same for messages moved manually as well as filtered emails Actual Results: The moved email re-appears in inbox Expected Results: The moved email should not re-appear in the inbox, as it has been copied to another folder. I'm using pop email. I recently updated from openSUSE_13.1 where emails moving and filtering worked just great ( as expected ). Currently running kmail-4.14.10. Looks a bit similar to bug report: 350059 But indeed also for me email filters are at the moment not usuable. Restarting akonadictl does not help.
I can confirm this behaviour, both on 4.14.8 and 4.14.10 (Akonadi 1.13.0), at least for one user on my machine. I tried to reproduce it for a test user but so far could not see this bug there. Additional observations: - It does not seem to be a matter of downloading the message again (although I did not test with network switched off), but the "seenUidList=..." entry in the [LeaveOnServer] section in ~/.kde4/share/config/akonadi_pop3_resource_0rc is not modified by moving the mail. - The Mail is moved correctly to the new folder, at least according to the browser in AkonadiConsole. The "reappearing" mails in the inbox get new and unique IDs though, although the "Remote Id" stays the same (still according to AkonadiConsole). - In accordance with this finding, there still is an email file (with filename-remote id) in the inbox folder (in the filesystem), even after moving the mail and _before_ the mail reappears in KMail's display. Interestingly, the _target_ mail directory does not have a file system representation, maybe because it's small enough to be completely buffered in Akonadi? I will test if this factor discriminates if the bug occurs.
Indeed! When moving the mail to a folder for which a file system representation exists (e.g. ~/.local/share/local-mail/Personen/ on my machine): 1) The mail file (my test case: "1452111445.R691.droggelbecher:2,S") is moved correctly to the new location, disappearing from the original file system folder. 2) The mail does not reappear upon revisiting the inbox.
For me personnally ( original poster ) the problem has been solved in the meantime. But this took a lot of effort. Too much to describe what I did. But it basically boils down that I removed the pop account and started from scratch, but whether that actually is the only thing that's need, I don't know. For me this report can be closed ( although it would be better to have the real problem solved ).
I had now a gdb session with Daniel and we could found the base problem, that gentBasePrivate::itemMoved is not triggerd in that specific case. The reason, why it is not triggerd is that the if in ResourceBasePrivate::itemMoved l294: void itemMoved(const Akonadi::Item &item, const Akonadi::Collection &source, const Akonadi::Collection &destination) Q_DECL_OVERRIDE { if (item.remoteId().isEmpty() || destination.remoteId().isEmpty() || destination == source) { changeProcessed(); return; } AgentBasePrivate::itemMoved(item, source, destination); } in our case: item.remoteId().isEmpty() = false destination.remoteId().isEmpty() = true (destination == source) = false so we exit the job directy and do not forward the itemMoved to AgentBase so the resource itself can't move the files at all. As daniel discribe above, the dest collection do not have a local folder representation and is only a "virtual" folder in akonadi. And because the (maildir) resource don't get the notification at all, so it can't fix the problem.
I am not sure what the intended policy is for 1) maildir folders whose content exists exclusively in the Akonadi DB and 2) moving _existing_ mail files to such destinations. If the folders (1) existed, this problem would not occur, but of course this might not make too much sense if (2) they would not receive any content anyway. I just hope that any fix would also work in the case of such not-yet-existing destination folders.