@martin-grotzke said in UID of imported invitation/event overwritten: Then the issue is only, that for the first sync the ics that DAVx sends to SOGo does not contain METHOD:REPLY (and in consequence on organizer side the attendee status is not updated). But this METHOD:REPLY is set when I accept/decline the invitation after the initial sync was done. Would it make sense to set METHOD:REPLY for the initial sync already if the organizer is not the attendee for that the invitation was accepted/declined? DAVx⁵ never sets METHOD, because this is CalDAV Scheduling, which is not supported by DAVx⁵. The Android calendar provider doesn’t have the possibility to store the required fields for that. But this METHOD:REPLY is set when I accept/decline the invitation after the initial sync was done. I don’t understand that. Do you think DAVx⁵ sets METHOD:REPLY? It’s only possible that it keeps it as an “unknown property” when it has received it from the server.

Thanks for the whole file, I’ll have a look.

Yes this helped, thank you

I emailed this to support, and they referred it to their 3rd line support. I guess they will fix it - or not. There is not much I can do now but wait and see if it starts working at some point. I guess this is not a common problem, otherwise some user-agent spoofing option could fix this more generally(?)

@otiel Thanks for the update!

OK, so i can ask the kolab people if they have any idea about the problem. But like i wrote bevor, it was working with this config for a couple of month without any problems. also my network settings didn´t changed in the last month… And i have no idea where i can check this on the kolab site… But i hope i will get this fixed.

@acu Works here again, too. I’ll set this to solved.

@bingo Thanks for the update!

@Dan-cer Thanks for the update! Good that it now works for you

@executive Of course this would be desirable. I have created a feature request for that: https://github.com/ical4j/ical4j/issues/350

Sorry for the delay: Works for me! Thanks a lot for helping!

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.

Hello, The server return’s an internal server error, probably because it couldn’t process one of its events. Please contact the server support.

Hello, Although there is no debug info, it seems that Nextcloud returns an error when DAVx5 requests the events/contacts. Is there any indication that this could be a DAVx5 problem?

It works! Thanks!

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.

@Saroumane Thanks for the update!

Good to know. I was already wandering. I was using aCalendar, not aCalendar+. In the free version it is not provided. Thanks for the quick feedback … Max

@hidde Thanks!

@nate2014jatc Maybe you could ask in the Nextcloud forum. As far as I know, issues are better for reporting bugs than asking questions, and it will take longer to get an answer.