I’d love to have options like
synch only between X o’clock and Y o’clock
synch only on ( ) Monday ( ) Tuesday ( ) Wednesday… etc
The reason for this request is servers that are not available at certain times, eg office machines that are switched off at night and at the week end. Choosing time frames, when to synch and when not, would avoid error messages.
HTTP 204 No Content must not have a body and thus Content-Length (which is the definition of 204). It seems like your server has returned HTTP 204 with a body, which does not make sense and can’t be interpreted. Please fix your Web server/application server.
Another thing which I don’t understand: Why even use X-APPLE-OMIT-YEAR if 1604 is assumed in any case? Why not just write partial dates as BDAY:1604-mm-dd (and assume that every date with 1604 is a partial date), wouldn’t it be the same?
Or does Apple use X-APPLE-OMIT-YEAR=1605 (or another non-1604-year) if the BDAY year is really 1604?
That is indeed a good question. I’ll try to do some tests when I get the next chance to test with an iPhone (I don’t have one myself).
Why can’t the server be improved so that it understands vCard 4?
Simply because the server is not under my control. I agree that upgrading the server really is the only way to add new features though.
Restrict Android to not offer partial dates in the contact schema at all, so that users cannot enter partial dates. This is how it has been until users have explicitly requested this feature because it’s available in Android and it’s available in vCard 4. Unfortunately, it’s not possible to (dis)allow partial dates according to server vCard 4 support because this support may change from sync to sync (and even if it wouldn’t, it can’t be set per account in Android).
I wasn’t aware of that.
So, there’s always a case with inconsistent behavior, which is a logical consequence of the fact that vCard 3 doesn’t support partial dates.
Now: Which case is more important?
To be honest, the arguments for both sides are pretty good and I’m no longer sure which one really is the best choice. (Maybe unless the answer to "
Or does Apple use X-APPLE-OMIT-YEAR=1605 (or another non-1604-year) if the BDAY year is really 1604?" is yes, since option 3 would probably cause the least loss in that case.)
yes I have, but I have to find an alternative way to reaching my NAS since I can’t just do https://nas.mydomain.com:8443 as I am using a reverse proxy to make sure my subdomains point to specific ports on the NAS.
My current setup is:
I have a subdomain (contacts.mydomain.com) (443) which points to my DDNS mydomain.ddns.net. The DDNS points to my network, and the 443 reaches my NAS, goes through a reverse proxy and points to a specific port in the NAS (in this case 8008). I need to do this to make sure I have a recognised SSL certificate from my domain.
Again, this setup works (if I open a browser and go to contacts.mydomain.com, it asks me username and password, and I can access the cardDAV (contacts.mydomain.com is sending me to http://192.168.1.200:8008/addressbooks/users/alex/ via reverse proxy).
I understand that DAVx5 wants a diskstation.example.com:8443 type of address, but I can’t just appent the port number to my nas address, as it would not recognize the SSL cert
No, in the eGroupware I could change the color of a category but not of a infolog.
In the past I could do it in the caldav Programm (also for the cards part)
Open Task have also no option to change the color.
So this could be a feature request for davx5
Yes, Google is changing a lot all the time and they deprecated older APIs recently. Some people report its working, but we’ve now disabled the entry again, because it makes too much trouble for us to support a service which constantly changes and which is also not very well tested by Google itself.
Thanks for the test account. When DAVx⁵ queries the resources, the server sends:
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:a="urn:ietf:params:xml:ns:carddav" xmlns:D="DAV:"><D:response><D:href>/SOGo/dav/c%26m@example</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><a:addressbook-home-set><D:href xmlns:D="DAV:">/SOGo/dav/c&m@example/Contacts/</D:href></a:addressbook-home-set><D:group-membership/></D:prop></D:propstat></D:response></D:multistatus>
which causes this DAVx⁵ error: Couldn't parse urn:ietf:params:xml:ns:carddavaddressbook-home-set EXCEPTION org.xmlpull.v1.XmlPullParserException: unterminated entity ref (position:TEXT @2:247 in okhttp3.ResponseBody$BomAwareReader@abfda3c)
As you can see, the & is not escaped in the href element, which is invalid XML and can’t be parsed. So, this seems to be a server problem and it seems to be related to the bug report you have posted.
If there are any specific indications that this could be a DAVx⁵ problem, please let us know.
Thanks for the explanation. I guess it was a problem with Baïkal after all.
I have “fixed” it by switching to DAViCal.
Very intimidating documentation & UI, but almost nothing needed to be configured and it Just Worked.
DAViCal is the server
DAVx5 syncs everything on Android
on the desktop I use vdirsyncer & khal for the calendar only (vdirsyncer still refuses to sync my contacts), and SoGo connector for contacts on thunderbird.
It’s been a long day.
I had the same problem where I was able to enter my account in davdroid and Davdroid itself successfully found all my calendars, however none of them would sync with the phone’s calendar programs (both the native calendar and e-tar). Seems like a bug / change in android 7 broke calendar syncing. I was unable to get davdroid to work for months, however now that there’s a new DAVx5 client I decided to try it. They fixed it! The link is broken in the fdroid repo’s BTW, however I managed to install davx5 manually and everything’s working. So if anyone else has the same issue, give the new davx5 a shot!
@Kim-Heinrich “Synchronization with Google CalDAV/CardDAV is not officially supported by Google or DAVx⁵. For some people it seems to work, for others it doesn’t. Google officially requires OAuth 2, which is not supported by DAVx⁵.” If you have suggestions for better wording, please let us know. Of course you can always get a refund, although those Google problems costs us work time without any benefit. Just write to firstname.lastname@example.org or in forum chat
Thanks for the screenshot. I was looking in the wrong place (system settings -> accounts). However, I really think that I had tried this button, with no effect (but I can’t test this anymore), so forget it.
Anyway, the current label in French does not have exactly the same meaning:
In this screenshot it is “adressbücher neu erkennen” which I suppose could be translated by “discover new address books” (it is a guess based on what I found in online translators)
in French it is “Actualiser le carnet d’adresses” which would be literally translated by “update address book”.
I am using DAVx5 188.8.131.52-ose(267). So I joined Transifex to check the translations, and indeed, the German translation has the good meaning. I just updated the French translation to fix this issue (strings 103 and 105):
Refresh address book list -> Actualiser la liste des carnets d’adresses
Refresh calendar list -> Actualiser la liste des calendriers
Synchronization with Google CalDAV/CardDAV is not officially supported by Google or DAVx⁵. For some people it seems to work, for others it doesn’t. Google officially requires OAuth 2, which is not supported by DAVx⁵.
We have received updated information about Google CalDAV:
The old endpoint https://www.google.com/calendar/dav is deprecated and no longer supported.
Now you shout suggest https://apidata.googleusercontent.com/caldav/v2/calid/events
Please have a look on https://developers.google.com/calendar/caldav/v2/guide
Google Account security:
If you use 2-Step-Verification for your Google account (recommended): Create an app password for DAVx⁵ and use the app password for signing in with DAVx⁵.
If you’re not using 2-Step-Verification: To allow Basic auth clients like DAVx⁵ to connect, you need to “Allow less secure apps” in your Google account before setting up DAVx⁵.
If you have further information, please just post here.
So I’m trying to connect DAVX5 with a Nextcloud service on an onion address but run into some problems. I’ve got version 184.108.40.206 of DAVX5 from Fdroid and version 15.0.7 of Nextcloud. And as I said I’m running it as hidden service so I need to connect to an .onion address and on the same device I’ve got Orfox and with I can connect to the onion address. But not with DAVX5. I get HTTP 405 Method Not Allowed. When I look into the apache logs on the server there is nothing special there at all.