Upcoming version of contacts app displays some names in a scrumbled way

[arkascha]

Testing the upcoming version of the contacts app as offered for download in issue #552 I saw that part of my contacts (about 50%, roughly) are displayed with the contact name scrumbled:

Instead of of usual name, surname or sometimes surname name those contacts are shown as ["name", "surname"]. In addition the icon left of the contacts in the list features a {{ instead of the usual first letter of the name.

The edit view of such contacts shows nothing special.

Further investigation appears to indicate that this is an issue with the display name is formatted in the data sets. That is the FN field in the vcard format

Since this result shows on a system that had issues with newer versions of the contact app before (see already mentioned issue #552) chances are that we are seeing another effect triggered by the actual data that already lead to a crash in the app for the last months.

---

Examples:

• an entry shown correct:

BEGIN:VCARD
VERSION:4.0
FN:Silke Musterfrau
N:Musterfrau;Silke;;;
PRODID:-//dmfs.org//mimedir.vcard//EN
TEL;TYPE=CELL,VOICE:+495550123456789
UID:7a9a431d-3852-4bdd-9276-5abf344ddce4
END:VCARD

"Silke Musterfrau","","Silke","","Musterfrau","","","","","","","","","","","","","","","","","","","","","","","","","+495550123456789","","","","","","","","","","","","","","","","",""

• an entry shoen scrumbled s described above:

BEGIN:VCARD
VERSION:4.0
EMAIL:[email protected]
FN:Mustermann\, Volker
N:Mustermann;Volker;;;
PRODID:OPEN-XCHANGE
UID:[email protected]
END:VCARD

"Mustermann, Volker","","Volker","","Mustermann","","","","","[email protected]","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""

The system showing this issue is an owncloud-9.1.4 installation on a Linux-x86_64 system, Ubuntu based. The installation works fine so far.
PHP-7.0.13
mysql Ver 14.14

[DeepDiver1975]

Works for me .... using current master ...

[DeepDiver1975]

Let me bundle a new release cadidate and let's see ...

[DeepDiver1975]

@arkascha here we go
contacts.zip

[arkascha]

That version unfortunately does not change the issue:

[DeepDiver1975]

😢

[DeepDiver1975]

Any error in the browser console?

[arkascha]

Nothing in the browsers console, sorry.

I just took a look into the database, I fail to see any structural difference between contacts displayed correct and such getting scambled.

[DeepDiver1975]

Within the setting in the bottom left corner there is a sort order setting - mind switching between the modes? Maybe we get some different display? THX

[arkascha]

Changing the sort mode from "Anzeigename" to "Vorname" or "Name" party fixes the issue, since obviously it is the "Anzeigename" that is causing issues here. However the icon featuring the strange {{ stays broken.

[DeepDiver1975]

Changing the sort mode from "Anzeigename" to "Vorname" or "Name" party fixes the issue, since obviously it is the "Anzeigename" that is causing issues here. However the icon featuring the strange {{ stays broken.

this gives some pointers at least ..... THX

[DeepDiver1975]

I can reproduce this behavior is I remove the \ from the FN

Works:

FN:Mustermann\, Volker

Causing issues:

FN:Mustermann, Volker

[DeepDiver1975]

[DeepDiver1975]

lets see if I can find a fix tomorrow ....

[arkascha]

Ok, seems like that backslash got removed when importing the contacts from my local PIM suite (exported as VCards) into ownCloud in a much earlier version. If so, then one might consider this corrupt data that should be fixed instead of getting worked around.

I wonder about that logic, though... why is the backslash required? The "display name" is a separate field (design decision in the VCard format). So I would expect it to be plain text and to get displayed "as is". Which not only obviously is not the case, but apparently that unescaped comma even gets interpreted in some strange way. That indeed might be something that should be examined...

I personally am happy if I can fix the issue on database level.
However I daresay that there are many users out there who have a similar collection grown over time with similar corruption (if it is such). Working around that (or automatically fixing it, though that is risky) might prevent many users getting frustrated again, especially since previous versions of the app did not show the current behavior and other contact solutions used by me (3 different) also seem to have no issue with those entries.

[DeepDiver1975]

I wonder about that logic, though... why is the backslash required?

the vcard specification defines the comma to be a value separator - in case the comma is to be used within the value it has to be escaped with a \

the definition that fn is a single string value only applies afterwards when the value is already parsed and exists as an array of two elements.

[arkascha]

Ok, thanks, das decides the cause of the issue: corrupted data in the owncloud database
I found the old VCard export file I used to import my address collection into owncloud years ago. Aren't backups a wonderful thing? ;-)
That file does contain the backslashes, so the VCard file itself is not corrupted, but the imported data is. To me that clearly indicates an error in (at least) previous versions of owncloud that corrupted data during the import.

Question is: should that get fixed automatically somehow? Certainly possible. Or should that be documented and handled as "legacy data"?

[DeepDiver1975]

Question is: should that get fixed automatically somehow?

well - this is not that easy from my understanding. This would require a hugh collection of possible corrupted cases and rules on how to fix them.

Starting with oc10 the server backend is much more restrictive on import of data and it should not be possible to import corrupted data - if this case is handled is to be tested.

[arkascha]

As said: the data that got imported is not corrupted as I see it...

With "possible to fix" I meant: only existing FN entries in VCards inside the database should get fixed: any comma in there that is not escaped by a backslash should be preceded with a backslash. That certainly will not fix potential other issues, but the issue at hand.