Syncs only own collections as opposed to all calendars one is allowed to see

  • developer

    If it is implemented, what is the risk if these properties remain in draft?

    The main reason why I have given up to implement it the last time is because there’s no equivalent thing for CardDAV.

  • While it is frustrating that there is not a CardDAV equivalent, I personally couldn’t see that as justification to not include this feature, or class adding a set of draft properties as a risk.

    Appreciated the quick reply.

  • Hi all,
    my ticket was linked here and read the discussion above.
    My Config is a Radicale server with connected DAVdroid, InfCloud and Thunderbird with SoGo and Lightning.
    InfCloud using the possibility to add additional Collections to look at.
    SoGo/Lightning only accept full path.
    So if the user is giving a full path like https://server/collection/calendar.ics/ davdroid should try to connect. Only if this fails go back in the tree to https://server/collection/ and try again. If this also fails use “well_known” etc… If a full path is given only show the calendar or address-book to add for synchronisation.
    Using a full path to a calendar or address-book should always work.

  • The process you’ve described chris5560 is identical to what is used on an iPhone to access a shared calendar. The downside is that the iPhone calendar software will also trigger reminders from the shared calendar as well. This is not so helpful when I’m adding my calendar to my wife’s device.

    My understanding is that this is a client issue. In other words, the CalDAV server should not be expected to remove alarms from calendar events for a non-owner. Instead the client should suppress the alarms.

    With this assumption in place, DAVdroid should determine if the authenticated user is the owner of the calendar, and suppress reminders. It could also be a checkbox option when adding a calendar. This suppression would hold regardless of whether DAVdroid used the full path or checked the calendar-proxy-read-for and calendar-proxy-write-for properties.

  • I thinks the most flexible way is to allow specifying the path of the principal in URL, and if it’s specified, firstly send PROPFIND to that location and only after that make auto-discovery. And than list all founded collections (url+discovery).
    For now the path in URL is ignored, I think davdroid should honor it and act as described. Or there could be a hidden path field.
    Anyway, to support most servers and cases, option for specifying path should be implemented.

  • Because it ist possible to present and select more than one calendar, I think detection should work as it is right now PLUS DAVdroid respecting any full-path given by the user and just “adding” this, if not already in the list of autodetected paths. This would not require and “pre-emptive” implementation of un-released drafts, but just create the option for “knowing” users to achieve what they want with a minimal effort.
    From my point of view this is not a “silly idea”, but we have seen several users in this thread requesting such a feature and giving argument why they would need it.
    I still like the idea of having a support for calendar-proxy-write-for property as additional feature to assist more users “out-of-the-box”. Having a parameter in the dialogue is even better, leaving the default behaviour as is is.

  • +1 here. Respecting full calendar paths would already be good.

  • Hello,

    I’m running Radicale 0.10 with two users and I wanted to share a calendar between them. I created one at user1 and indicated to Radicale that user2 can RW this calendar.
    As indicated above, Davdroid never detected this new calendar, even removing and re-creating the account.
    I finally made a link (ln -s) to this calendar to the user2 folder, this way Davdroid detected it.

    Any way to have the possibility to add ‘external’ calendars (or address books, or tasks list) to Davdroid may be really interesting. If it can be done automatically (maybe there is no way to detect them), at least add the possibility to add it manually. May be related to #219 and all other ‘calendar editions’ issues.

  • developer

    Just looking for a working calendar-proxy setup for testing…

    Anyone willing to test?

  • developer

    Now (DAVdroid 1.0), group memberships of the current user are queried for home sets, too. This means that if a user is in the calendar-proxy-{read,write} group (as described in Calendar User Proxy Functionality in CalDAV), those proxied resources should be detected too. Furthermore, this could be used for address books, too, by adding similar groups.

    If you’re interested in that, please test it in the beta version.

Similar topics