Request for Feedback: New CalDAV and CardDAV implementation for Kopano

Hi @norman,

thanks for your feeback. I have adopted the readme a bit.

@norman said in Request for Feedback: New CalDAV and CardDAV implementation for Kopano:

“ln -s /usr/share/kopano/php/mapi /var/www/kdav”: mapi directory doesn’t exist on my server, main kDAV directory is selectable in the start of the installation guide

I think this is probably because of your old Kopano installation, for me this path exists.

One thing I noticed:

In my main calender there ist a folder “Abfall”. In “principals/norman” “/calendars/norman/Abfall/” is the “schedule-default-calendar-URL”.

d:owner	                                /principals/norman/
cal:schedule-outbox-URL	                /calendars/norman/outbox/
cal:schedule-inbox-URL             	/calendars/norman/inbox/
cal:schedule-default-calendar-URL	/calendars/norman/Abfall/

Norman

Hi,

First of all I am very happy that Kopano has decided to implement CardDAV! Now I do not need MS Exchange anymore which I cannot get to work on my Android cell anymore since Oreo, so this is great.

However, I have two points of feedback / bugs which need to be ironed out before I can use it productively:

  1. International characters like german umlaut ä, ö, ß or others like ć are not working for names, addresses, it’s a total mess. They can be stored like that in the webapp, but once transfered to a cellphone it’s not working.

Using export2csv.php file shows that everything is correct, all the umlaute are there. But they appear not to be UTF encoded - my Ubuntu terminal shows a slight difference in how a character is displayed in terminal in case of ASCII or UTF, the later being more “drawn” style and a bit bolder. However, this download works.

To test kdav I used on my Android cellphone:

a) Davdroid - cannot communicate with kdav (but works fine for my Nextcloud Server)

b) contactsync (https://play.google.com/store/apps/details?id=com.vcard.android.free) - works for downloads of contacts. Uploads do do not work well. Looking at the kdav logs I can see that contactsync is sending the VCF data with a “characterset UTF-8” in the HTTP header, but the result is that the kopano database gets data which is not double byte but two single bytes.
Consequences:

  • The characters are not “ä” anymore but are two digits which are the two single bytes of the unicode character - export2csv.php also shows the same result
  • The contact in the webapp is a new contact if the name was changed causing a different ID (with the old contact remaining)
  • Upon a new sync to contactsync the “ä” is now also replaces with the two single bytes
  • In turn, upon sycing with kdav the two single bytes which contactsync sends are now each replaced with two new single bytes - so in total taking it from 1 character to 2 characters and now to 4 characters. You can imagine what happens upon the new download and upload I guess?

To me it looks like kopano does not interpret the codepage in which the client sent the data (I can clearly see the double byte character in my terminal as it’s a different visual style as normal) - kdav always converts the input in some way which is wrong / not required causing serious problems.

  1. Birthdays
    These are stored as UTC timestamps in Kopano. Nothing wrong with that.
    What is wrong however is that these birthdays are not sent in an expected format “YYYY-mm-dd” - they also contain a timezone… This may be OK based on e.g. rfc6474 for “deathdate”. But the problem is that using a UTC timestamp usually triggers code to do a conversion into the timezone of the client - this is the correct behaviour. But this requires that the client and server both “understand” what each one does, if one does it differently then there will be problems.
    For me, a contact has the bday “1990-09-05”. This is how I see it in the webapp. When I export this contact it is sent with a UTC timestamp of 4th september 11:00pm. This makes the client set the bday as 4th September. In other cases kdav sends it as 0:00am - no idea why, maybe due to DST?
    Now one can start arguing “kdav is doing it right, the client should fix it”. But the trivial approach is just to always STORE the bday in UTC+0 and send the bday as YYYY-mm-dd - without ANY conversion at all to the client. Then there can never be any mixup as no client will do any timezone adjustments as it doesn’t know the timezone.
    And another argument - Nextcloud, which also uses sabreDav, works perfectly fine also for the birthdays of my contacts.

This should be trivial to reproduce. TIll these issues are solved, I’m using my Nextcloud Server for my contacts.

I’ve tried but always get:

Fatal error: Uncaught PDOException: SQLSTATE[HY000] [14] unable to open database file in /var/www/kdav/lib/KopanoSyncState.php:45 Stack trace: #0 /var/www/kdav/lib/KopanoSyncState.php(45): PDO->__construct(‘sqlite:/var/lib…’) #1 /var/www/kdav/lib/KopanoDavBackend.php(48): Kopano\DAV\KopanoSyncState->__construct(Object(Kopano\DAV\KLogger), ‘sqlite:/var/lib…’) #2 /var/www/kdav/server.php(54): Kopano\DAV\KopanoDavBackend->__construct(Object(Kopano\DAV\KLogger)) #3 {main} thrown in /var/www/kdav/lib/KopanoSyncState.php on line 45

/var/lib/kopano/kdav is owned by www-data:

drwxr-xr-x 2 www-data www-data 4096 Dez 11 17:28 kdav

php-sqlite3 is installed. System is devuan ascii. Kopano 8.6.81, php7.2

Can anyone help? Thanks in advance!

@Fux how are the permissions of the file itself? so /var/lib/kopano/kdav/syncstate.db?

@fbartels said in Request for Feedback: New CalDAV and CardDAV implementation for Kopano:

“ln -s /usr/share/kopano/php/mapi /var/www/kdav”: mapi directory doesn’t exist on my server, main kDAV directory is selectable in the start of the installation guide

just a node on that. since we recently removed the mapi classes from php-mapi they are now part of the repo itself and no symlinking is required anymore.

The file /var/lib/kopano/kdav/syncstate.db doesn’t exist yet. I tried to create (with touch) and set the right permissions - but no success.
I thought it would be created at first time kdav runs?

@Fux said in Request for Feedback: New CalDAV and CardDAV implementation for Kopano:

I thought it would be created at first time kdav runs?

Yes, that is indeed what should be the case. The remaining conclusion is that you are running apparmor or something similar and that prevents php from writing into this folder.

Solution: adapt your apparmor config or change the location of the file into /var/www in the config of kdav

After changing the path to /tmp only for testing) it works and file is created. Must be something wrong with my /var/lib/kopano/kdav.
Although I have no apparmor installed (selinux either) and the permissions look good.
OK, but this seem to bbe a special problem with my system.

Thanks for your help!

Hi,
thank you for working on a complete dav implementation for kopano. It is appreciated!
In my test installation it works fine for the most part. However I do encounter similar problems with special characters (ä/ö/ü/…) as described by MichaelAnders2.
Entering a name with “ä” in kopano webapp and syncing it to android ==> OK, correctly displayed in android.
Entering a name with “ä” in android an syncing it to kopano server/webapp ==> Not OK, Character is displayed like “ä” in webapp.
I am using Kopano Core: 8.6.82 and WebApp 3.4.3.1137+674.1, running on nginx 1.10.
My smartphone uses android 8.1 and DavDroid (I also tried CardDav with the same result).
Thanks for your good work!