Bug 317966

Created attachment 78695 [details]
The test .vcf

Well, you can also just import the uppercase form of the .vcf
It leads to the same result.

Created attachment 78696 [details]
Uppercase form of the test .vcf

just import this file to see the bug

Seems to be the same bug as here ( Bug 307618 - parsing problem with anniversary property converted to upper case ).
Just some more fields.

This could fix this issue. 

BUT be carefull it is not tested!

What did I do?:
- I followed the fix in Bug 307618 .
- X-Profession is removed because it is already in the set.
- Added the upper case version of every key

diff --git a/akonadi/contact/editor/customfieldseditwidget.cpp b/akonadi/contact/editor/customfieldseditwidget.cpp
index dc0cc6c..c4d1e00 100644
--- a/akonadi/contact/editor/customfieldseditwidget.cpp
+++ b/akonadi/contact/editor/customfieldseditwidget.cpp
@@ -120,9 +120,7 @@ void CustomFieldsEditWidget::loadContact( const KABC::Addressee &contact )
                       << QLatin1String( "X-ManagersName" )
                       << QLatin1String( "X-AssistantsName" )
                       << QLatin1String( "X-Anniversary" )
-                      << QLatin1String( "X-ANNIVERSARY" )
                       << QLatin1String( "X-SpousesName" )
-                      << QLatin1String( "X-Profession" )
                       << QLatin1String( "MailPreferedFormatting")
                       << QLatin1String( "MailAllowToRemoteContent")
                       << QLatin1String( "CRYPTOPROTOPREF" )
@@ -130,6 +128,11 @@ void CustomFieldsEditWidget::loadContact( const KABC::Addressee &contact )
                       << QLatin1String( "SMIMEFP" )
                       << QLatin1String( "CRYPTOSIGNPREF" )
                       << QLatin1String( "CRYPTOENCRYPTPREF" );
+            QSet<QString> upperCaseBlacklist;
+            foreach(const QString& blacklistEntry, blacklist) {
+              upperCaseBlacklist << blacklistEntry.toUpper();
+            }
+            blacklist.unite(upperCaseBlacklist);
         }
 
       if ( blacklist.contains( name ) ) { // several KAddressBook specific fields
diff --git a/akonadi/contact/standardcontactformatter.cpp b/akonadi/contact/standardcontactformatter.cpp
index 8bbdb5f..0acc23d 100644
--- a/akonadi/contact/standardcontactformatter.cpp
+++ b/akonadi/contact/standardcontactformatter.cpp
@@ -214,6 +214,13 @@ QString StandardContactFormatter::toHtml( HtmlForm form ) const
     titleMap.insert( QLatin1String( "IMAddress" ), i18n( "IM Address" ) );
     titleMap.insert( QLatin1String( "Anniversary" ), i18n( "Anniversary" ) );
     titleMap.insert( QLatin1String( "AddressBook" ), i18n( "Address Book" ) );
+    QMap<QString, QString> upperCaseTitleMap;
+    QMap<QString, QString>::const_iterator iterator = titleMap.constBegin();
+    while (iterator != titleMap.constEnd()) {
+      upperCaseTitleMap.insert(iterator.key().toUpper(), iterator.value());
+      ++iterator;
+    }
+    titleMap.unite(upperCaseTitleMap);
   }
 
   static QSet<QString> blacklistedKeys;
@@ -242,7 +249,7 @@ QString StandardContactFormatter::toHtml( HtmlForm form ) const
         if ( key == QLatin1String( "Anniversary" ) || key == QLatin1String( "ANNIVERSARY" ) ) {
           const QDateTime dateTime = QDateTime::fromString( value, Qt::ISODate );
           value = KGlobal::locale()->formatDate( dateTime.date() );
-        } else if ( key == QLatin1String( "BlogFeed" ) ) {  // blog is handled separated
+        } else if ( key == QLatin1String( "BlogFeed" ) || key == QLatin1String( "BLOGFEED" ) ) {  // blog is handled separated
           continue;
         } else if ( blacklistedKeys.contains( key ) ) {
           continue;

I've tested with the first version of your test file and the latest of 4.10 in the Git repo and the issue is not present (ownCloud does not uppercases the fields). I've changed a bit the way contacts are imported, so that may explain and in that case the issue seems to be in the VCard converter.

However with your second test file the problem arises. Which client generated this file? Is it with the DAV resource only?

(In reply to comment #6)
> (ownCloud does not uppercases the fields).
Well, in my ownCloud mySQL Database the fields are all uppercase.

> However with your second test file the problem arises. Which client
> generated this file?
I simply exported the contact after the resync. (And removed one ownCloud specific line. (PRODID:-//ownCloud//NONSGML Contacts 0.2.5//EN))

> Is it with the DAV resource only?
With the second test file, no.

(In reply to comment #7)
> (In reply to comment #6)
> > (ownCloud does not uppercases the fields).
> Well, in my ownCloud mySQL Database the fields are all uppercase.

Ah, right, the bug fix came in the way :) Changing a bit the contact in ownCloud and refreshing it did the trick.

I'm re-assigning to the right product.

I forgot two lines in the fix above:


@@ -224,6 +231,8 @@ QString StandardContactFormatter::toHtml( HtmlForm form ) const
     blacklistedKeys.insert( QLatin1String( "CRYPTOSIGNPREF" ) );
     blacklistedKeys.insert( QLatin1String( "CRYPTOENCRYPTPREF" ) );
     blacklistedKeys.insert( QLatin1String( "MailPreferedFormatting" ) );
+    blacklistedKeys.insert( QLatin1String( "MAILPREFEREDFORMATTING" ) );
+    blacklistedKeys.insert( QLatin1String( "MAILALLOWTOREMOTECONTENT" ) );
     blacklistedKeys.insert( QLatin1String( "MailAllowToRemoteContent" ) );
   }

*** Bug 317767 has been marked as a duplicate of this bug. ***

Would be cool, if this fix made it into KDE 4.10.3.

Bernhard,

Have you tested your patch? If so, does it work as intended? I'm still a bit worried about the "BUT be carefull it is not tested!" part in comment #5 :)

If you're satisfied with it I can ask for a first informal review on the kde-pim@kde.org mailing list, but it's better if you can confirm that it's at least working for you.

Cheers,
Grégory

Can someone give instructions how to compile it with this patch. Then I am willing to test it :-)

So, i somehow tested this patch by modifying the compilation instruction you gave me in the other bug and handediting the above patch into the files. Everything went through fine. It appears to work, I could not find any problems of information put into custom fields. Although the problem still remains that only a part of the contacts shown in Owncloud are shown in Kaddressbook. I am not sure if this is related. I will file another bug

Is this patch supposedly applied? I have the same problem of case sensitivity on X-KADDRESSBOOK-X-PROFESSION with kmail/akonadi 2.14.7 and owncloud 8.0.3

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kdepim (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.

This is still present / reproducible in KAddressBook 5.3.0.

KDE Neon
KDE Frameworks 5.26.0 
Qt 5.7.0 (kompiliert gegen 5.7.0) 
Das xcb Fenstersystem

Git commit e39302f6b69c816b6f0208e3ce2f6672f340b43c by Montel Laurent.
Committed on 22/05/2017 at 05:50.
Pushed by mlaurent into branch 'master'.

Start to look at Bug 317966. Apply patch in this bug report

M  +5    -3    src/editor/customfieldeditor/customfieldslistwidget.cpp
M  +11   -1    src/standardcontactformatter.cpp

https://commits.kde.org/akonadi-contacts/e39302f6b69c816b6f0208e3ce2f6672f340b43c