View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002511||SOGo||Apple iPhone OS||public||2013-11-24 17:38||2017-05-30 19:50|
|Reporter||Benoit Locher||Assigned To||ludovic|
|Platform||iPhones and iPads||OS||IOS||OS Version||7.0.4|
|Fixed in Version||3.2.10|
|Summary||0002511: r letter appended to every item: names, numbers, etc|
When syncing contacts via CardDAV on iPhones and iPads, every item gets a letter 'r' appended to it. It occurs on names, numbers, etc.
See screenshot for example.
|Steps To Reproduce|
Sync contacts with iPhone/iPad from SOGo v2.1.1 running on Debian, browse contacts from client using the "Contacts" native application.
|Tags||No tags attached.|
I add the versions of the involved components in case it can help:
server: Debian Jessie/sid
Mysql database: InnoDB with utf8_general_ci interclassment.
iOS is version 7.0.4 in all cases.
Information was already filled-in under OS Version, but maybe this field was aimed at server version running SOGo? Sorry for the confusion.
I edited all my contacts field by field to remove the appended 'r' and they seem to remain clean (without the parasitic 'r' at the end of each field.
Creating a new contact from the SOGo web interface generates a clean contact from iPhone/iPad point of view, without 'r'.
My guess: I suspect this is due to the initial ldif import procedure?
Anyway this ticket severity can be lowered to 'minor' as I could edit and correct each contact (was done on the iPad directly, and with patience)
Could it be, that your ldif file uses windows line breaks (cr lf)?
If yes, could you try to change them to Unix/Linux line breaks (lf) (e.g. with dos2unix) and test again?
I will try this and report back. Maybe some '\r' be converted to 'r' for some reasons?
If I remember correctly, the ldif was created under debian from an export made with davical.
Now I remember what I did exactly: I exported my old davical address book from Thunderbird address book through the SOGo Connector (v24) as an LDIF file.
(Under Debian I had VCARD format actually, which I didn't use).
So opening this file with Notepad++ and showing all symbols reveals CR LF at the end of each item.
I'm now 99% confident that the appended 'r' come from this steps.
See attached extract of LDIF as viewed in Notepad++.
After this, I simply imported the LDIF back into the SOGo address book using the web interface and "Importer des contacts" context menu on the Address book entry.
I will perform an import test with a test environment to try the import with and without CR/LF. Will report back.
Did the following tests on a newly created address book using the SOGo web interface for one of my users. Software components used:
This confirms the suspicion!
Additional information: the entries with the parasitic 'r' were displayed correctly under Thunderbird address book and in SOGo web interface. The 'r' were only showing up on iPad/iPhone devices.
Can you retry with the nightly build of SOGo?
I can't reproduce the error.
After updating to SOGo 2.1.1b-1 my setup got broken, I get:
object not found: SOGo => index
From web interface :-(
I purged all files from sogo packages (Debian), reinstalled 2.1.1b-1 but still the same. I notice WebServerResources is missing in folder /usr/lib/GNUstep/SOGo
I'll try to fix this and revert for the test you proposed.
Ok, so I switched over to the nightly build 220.127.116.1140208-1.
I exported my current address book from Thunderbird to a .ldif file, created a new calendar in my SOGo account, and imported the contacts.
From my iPhone, I still see the parasitic 'r' (they do not show up on the web interface)
Did another test: updated my SOGo connector to 24.0.4 fetched today (sogo-connector-24.0.4-6c8ee8bcc2.xpi). Exported the contacts from Thunderbird 24.3.0 and tried to import the ldif filr from SOGo web interface.
The same happens: parasitic r seen on iPhone on this new address book.
For information, I just tested with newly released SOGo v2.2.0-1 (debian) and problem still exists.
Just got an report of this bug again with 2.2.4.
You need an LDIF file with <CR><LF> line endings instead of the <LF> ones (I made a one with unix2dos).
Actually, this is the opposite: importing an LDIF file with <CR><LF> will cause the parasitic 'r' to appear on iPhones/iPads (as stated in 0002511:0006372 ).
I just did the test again: exporting a SOGo address book to an LDIF text file, it has <CR><LF> line terminations. Importing this file into SOGo web interface will cause the 'r' to be appended on each entry.
Converting the LDIF file from <CR><LF> to <LF> before importing into SOGo clears the problem out.
Sorry, I should have said:
Yes, exacly. This is not a big problem per se when you know the cause anyway.
|2013-11-24 17:38||Benoit Locher||New Issue|
|2013-11-24 17:47||Benoit Locher||File Added: cdbug1.jpg|
|2013-11-24 17:47||Benoit Locher||File Added: cdbug2.jpg|
|2013-11-24 18:20||Benoit Locher||Note Added: 0006258|
|2013-11-24 18:22||Benoit Locher||Note Edited: 0006258|
|2013-11-25 14:04||Christian Mack||Note Added: 0006275|
|2013-11-25 14:08||Benoit Locher||Note Added: 0006276|
|2013-11-25 14:12||Benoit Locher||Note Edited: 0006276|
|2013-11-25 14:12||Benoit Locher||Note Edited: 0006276|
|2013-12-14 11:14||Benoit Locher||Note Added: 0006360|
|2013-12-14 11:16||Benoit Locher||Note Edited: 0006360|
|2013-12-16 07:59||Christian Mack||Note Added: 0006362|
|2013-12-16 08:03||Benoit Locher||Note Added: 0006363|
|2013-12-17 18:29||Benoit Locher||Note Added: 0006367|
|2013-12-17 18:30||Benoit Locher||File Added: sogoldifexport.jpg|
|2013-12-17 18:31||Benoit Locher||Note Edited: 0006367|
|2013-12-17 18:33||Benoit Locher||Note Edited: 0006367|
|2013-12-18 14:50||Benoit Locher||Note Edited: 0006367|
|2013-12-23 18:09||Benoit Locher||Note Added: 0006372|
|2013-12-24 07:12||Benoit Locher||Note Edited: 0006372|
|2013-12-24 07:13||Benoit Locher||Note Edited: 0006372|
|2013-12-24 07:15||Benoit Locher||Note Edited: 0006372|
|2013-12-24 07:17||Benoit Locher||Note Edited: 0006372|
|2014-02-07 14:08||ludovic||Note Added: 0006522|
|2014-02-07 14:08||ludovic||Severity||block => minor|
|2014-02-08 12:27||Benoit Locher||Note Added: 0006537|
|2014-02-08 14:21||Benoit Locher||Note Edited: 0006537|
|2014-02-08 14:22||Benoit Locher||Note Edited: 0006537|
|2014-02-13 06:04||Benoit Locher||Note Added: 0006544|
|2014-02-26 13:17||Benoit Locher||Note Added: 0006571|
|2014-07-25 14:29||Christian Mack||Relationship added||duplicate of 0002281|
|2014-07-25 15:01||Christian Mack||Note Added: 0007352|
|2014-07-25 15:19||Benoit Locher||Note Added: 0007353|
|2014-07-25 15:43||Christian Mack||Note Added: 0007354|
|2014-07-25 15:44||Christian Mack||Note Edited: 0007353|
|2014-07-25 15:45||Christian Mack||Note Edited: 0007353|
|2014-07-25 15:49||Christian Mack||Note Edited: 0007353|
|2014-07-25 16:32||Benoit Locher||Note Added: 0007356|
|2017-05-30 19:50||ludovic||Note Added: 0011886|
|2017-05-30 19:50||ludovic||Status||new => resolved|
|2017-05-30 19:50||ludovic||Fixed in Version||=> 3.2.10|
|2017-05-30 19:50||ludovic||Resolution||open => fixed|
|2017-05-30 19:50||ludovic||Assigned To||=> ludovic|