@rparkins True, this solution adds a lot of complexity (and thus open a Pandora’s box full with new bugs) for a very rare problem. But i will consider it. Thanks for your thoughts.
CalDAV: Sync colors after setup
-
Alright. So essentially I should remove the accounts again, turn on debugging and then hook it up once more?
Anything in particular I should look for in the logs?
-
Alright. So essentially I should remove the accounts again, turn on debugging and then hook it up once more?
Yes please, that would be very helpful.
Anything in particular I should look for in the logs?
There should be a PROPFIND request on your calendar-home-set. In the reply, there should be a color element. Further debugging will depend on whether it’s there and how it’s formatted.
-
I checked this and the response includes this:
<x5:calendar-color xmlns:x5="http://apple.com/ns/ical/">DC143C</x5:calendar-color>I suppose the problem is that the color is not given as
#DC143C. This is already fixed in Kolab.org upstream, but not rolled out to MyKolab.com. @rfc2822 can you confirm that DAVdroid chokes on the color value? -
I suppose the problem is that the color is not given as #DC143C. This is already fixed in Kolab.org upstream, but not rolled out to MyKolab.com. @rfc2822 can you confirm that DAVdroid chokes on the color value?
Yes, DAVdroid currently expects this pattern. I wonder whether it should be changed to allow color names without leading #. It’s really annoying to implement things by feeling and hearsay – I think there just is no standard for the
calendar-colorelement, although it has anxmlns. -
We could also not find specification for this. Here’s our ticket about the issue for reference. So since we changed to the leading #, you might as well stay with it. However, if you want DAVdroid to be more robust, you might as well make the # optional.
-
DAVdroid fetches the CTag for the collection on every sync – the same request could be used to fetch color, title and description again, too.
-
Given that we seem to know what is going on ("#" vs no “#”) it seems that debugging is no longer required. So if possible I’d avoid having to go through the cycle.
-
I think this can be closed.
-
Thanks for the hint, closing
-
I’m starting to use DAVDroid and wanted to know: How is the current behavior regarding color sync? Does it still download the colors at setup time?
-
Does it still download the colors at setup time?
Yes: At the moment, colors are only fetched here from the PROPFIND response, then put into
ServerInfo.ResourceInfoand then later used when creating theLocalCollections. -
I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections). See CalDAV-Sync for what I mean.
-
I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections).
Please follow up in in #219 and #243 for that.
See CalDAV-Sync for what I mean.
As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.
-
As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.
I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.
-
I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.
Ah ok, this is #219. Please follow up there.
I don’t know when this will be done, at the moment I’m happy about tasks sync
