Bug 303069

Summary:	KMail2 folders get indexed even when the Enable Full Text Indexing option is unchecked
Product:	[Applications] kmail2	Reporter:	leo_rockway <leo>
Component:	folders	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	montel
Priority:	NOR
Version:	4.9 pre
Target Milestone:	---
Platform:	Arch Linux
OS:	Other
Latest Commit:	http://commits.kde.org/kdepim/830cbf8b4681c2318931ba1366f439eaf6077bc2	Version Fixed In:	4.10
Sentry Crash Report:
Attachments:	KMail2 indexes folders even when told not to

Description leo_rockway 2012-07-05 16:45:41 UTC

I'm subscribed to a few mailing lists and I sort the emails in folders. I have set in the folders' properties to expire the messages after a week. For this very reason, I'm not interested in indexing these folders, since the content of them is merely temporary and I'm never going to be searching for items in them. However, regardless of the fact that the Enable Full Text Indexing option is unchecked, the folders get indexed anyway as informed by the dialog itself underneath that option. For instance, I have a folder which says "Folder was indexed: Thursday 05 July 2012".

Reproducible: Always

Steps to Reproduce:
1. Uncheck the Enable Full Text Indexing option on the Properties of Folder
2. Wait for indexes to work their magic
3. Folder gets indexed anyway
Actual Results:  
Folder gets indexed.

Expected Results:  
Folder shouldn't get indexed.

Comment 1 leo_rockway 2012-07-05 16:48:42 UTC

Created attachment 72335 [details]
KMail2 indexes folders even when told not to

Comment 2 Laurent Montel 2012-07-06 06:23:25 UTC

could you find email when your search in this specific folder ?
or you just have this info ?

Comment 3 leo_rockway 2012-07-06 06:45:15 UTC

I just checked and yes, I can find emails when performing searches in these folders. All my folders are getting indexed (I have about 15) but I only have full search index enabled in 3 of them.

Comment 4 Laurent Montel 2012-07-06 11:06:43 UTC

There is a check about it.
So I think that it's old indexing which is not removed when we disabled check.
I will fix it soon.

Comment 5 Laurent Montel 2012-07-06 16:51:57 UTC

Git commit 830cbf8b4681c2318931ba1366f439eaf6077bc2 by Montel Laurent.
Committed on 06/07/2012 at 18:50.
Pushed by mlaurent into branch 'master'.

Fix Bug 303069 - KMail2 folders get indexed even when the Enable Full

Text Indexing option is unchecked

Remove indexed text from collection when we unchecked it.

I can't backport to 4.9 because kdelibs/nepomuk was not full.
Now that we depend against nepomuk-core we can do it.

FIXED-IN: 4.10

M  +4    -1    kmail/collectionmaintenancepage.cpp

http://commits.kde.org/kdepim/830cbf8b4681c2318931ba1366f439eaf6077bc2

Comment 6 leo_rockway 2012-07-07 03:55:43 UTC

Thanks for the commit!

I'm not sure if I followed you correctly, though, but this wasn't old indexing that remained after I unchecked the indexing option. These are the steps I took:

0) I disabled indexing on the mail folders
1) I completely (manually) deleted all indexing
2) Some time later, the folders where indexing was disabled got indexed anyway

Maybe the case you mentioned was happening too, but (again, if I understood you correctly) it's not exactly my case.

Comment 7 Laurent Montel 2012-07-07 09:59:57 UTC

By default:
static inline bool indexingDisabled( const Collection &collection )
{
  if ( collection.hasAttribute<EntityHiddenAttribute>() )
    return true;

  IndexPolicyAttribute *indexPolicy = collection.attribute<IndexPolicyAttribute>();
  if ( indexPolicy && !indexPolicy->indexingEnabled() )
    return true;

  if ( collection.isVirtual() )
    return true;

  // check if we have a plugin for the stuff in this collection
  foreach ( const QString &mimeType, collection.contentMimeTypes() ) {
    if ( mimeType == Collection::mimeType() )
     continue;
    if ( !FeederPluginloader::instance().feederPluginsForMimeType( mimeType ).isEmpty() )
      return false;
  }

  return true;
}

=> it's disabled. so it can't index.

Comment 8 leo_rockway 2012-07-07 20:19:25 UTC

Great! Thank you very much for the quick resolution of this bug.