Recognise inbox collection from all resources
ClosedPublic

Authored by nowicki on Oct 27 2016, 9:20 PM.

Details

Summary

The goal of this patch is to fix mail filtering for non-IMAP resources. Currently the Mail Filter Agent will looks for inbox collections and only subscribe to items on these. The logic to find the inbox folders is to look for the default inbox collection or collections with remote identifier set to "INBOX". This will work fine for IMAP resources as their remote IDs follow the original IMAP folder name. For other resources, like Akonadi EWS the inbox folder is not guaranteed to have a meaningful name (in case of EWS this will be a long random-like base64 string).

The resource has the ability to indicate special collections in its tree, including the inbox collection. Unfortunately the folderIsInbox() method will not take this into account.

The patch changes the behaviour of the above method to not only use the default inbox collection but any collection that is marked as an inbox collection.

The only side-effect I have found is that the collection properties dialog in KMail will no longer allow changing the inbox collection icon as the code blocks this setting from all local or inbox collections. I guess this should be acceptable.

Diff Detail

Repository
R92 PIM: Common Mail Support
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
nowicki updated this revision to Diff 7707.Oct 27 2016, 9:20 PM
nowicki retitled this revision from to Recognise inbox collection from all resources.
nowicki updated this object.
nowicki edited the test plan for this revision. (Show Details)
nowicki added a reviewer: KDE PIM.
nowicki set the repository for this revision to R92 PIM: Common Mail Support.
Restricted Application added a project: KDE PIM. · View Herald TranscriptOct 27 2016, 9:20 PM
Restricted Application added a subscriber: kde-pim. · View Herald Transcript

Have you looked if maybe this could be fixed in SpecialMailCollections? That would automagically fix this problem in all places without having to change the code there, and I'm pretty sure there's more places where this method is used in PIM.

I don't really see how this can be fixed in SpecialMailCollections as it has the concept of default collection for a type, which expands to the special collection registered by the default resource. This means that it will always return one inbox collection. The idea behind this change is to allow each resource to register its inbox collection and then have all the other machinery treat all of them equally.

The MailCommon::Kernel class also contains other folderIsXxx methods which are used to test other collection types. I haven't touched these as I don't want to run into possible side effects, but maybe it would make sense to modify them accordingly to maintain a consistent behaviour.

dvratil accepted this revision.May 3 2017, 9:44 AM

Hi,

sorry for the huge delay, I kept delaying getting back to this forever :/ Thanks for your explanation, you are right about this. If we run into the issue elsewhere, we can fix it there eventually.

This revision is now accepted and ready to land.May 3 2017, 9:44 AM
This revision was automatically updated to reflect the committed changes.