DAVdroid stopped showing group resources

  • I have a user with which I log in. That user is part of a group. And the group has resources too.
    The user has a calendar and multiple address books, of which I select one.
    The group has one calendar and one address book.

    Previously, I made two DAVdroid accounts. One for the user, with …/caldav.php/username/ at the end of the URL, and one for the group, with …/caldav.php/groupname/ at the end. In both cases the user name and password were the same. (Those of said user.)

    Now, no matter what I put in the URL field, I always only get to select the user’s resources. The group resources are not shown.

    There have been zero changes to the DAViCal server. All rights are still set correctly.

    I think the version I previously used was a version before 0.6, with a -alpha at the end. I’m not sure which exact one though.

  • developer

    Thanks for your report. Please read Reporting issues and provide all information mentioned there, including detailled steps to reproduce the issue and verbose logs.

  • developer

    Does your installation support well-known paths? In this case, it doesn’t matter what you enter because the detected path will always be used. Well-known paths have been introduced with DAVdroid 0.6.

  • Ah, interesting. Yes, I had them enabled. I guess then I just disable them…

    Aaand it works! Thank you very much! 🙂

    Am I doing something wrong, or how come I can’t see those group resources with well-known paths enabled?

  • developer

    Am I doing something wrong, or how come I can’t see those group resources with well-known paths enabled?

    If the server reports well-known paths, these are used. There’s no other way because if you enter https://your.domain/ the “/” is the user-given path. So there’s always a user-given path, so when a well-known path is also available and working, it will be used.

  • Well, I wish well-know paths would only be used, if “no path” (you know) is manually specified.

    If I’d say …/caldav.php/mygroup/, and DAVdroid would then not use the well-knowns (outside of …/caldav.php/mygroup/), would that break anything?

  • developer

    Well, I wish well-know paths would only be used, if “no path” (you know) is manually specified.

    I think the exact behaviour is not specified in RFC 6764. However, I think if the server explicitely provides working well-known paths, they should be used because often, users will enter paths of calendars, CalDAV or CardDAV backends and don’t know what they’re doing. The result would be that if you, for instance, enter /remote.php/caldav CardDAV wouldn’t be detected.

    If I’d say …/caldav.php/mygroup/, and DAVdroid would then not use the well-knowns (outside of …/caldav.php/mygroup/), would that break anything?

    Yes, it’s an arbitrary choice to prefer either well-known paths or user input, but in my experience, admins (thus servers) are much more capable than end users.

  • The dreaded “certain users are morons, so let’s take away the freedoms of everyone else too” un-logic… hrm😕
    I think mindsets like this are very harmful to humanity in the long term, and the main cause of the current Idiocracy.

    But it’s your software, of course, and you’re not wrong.

    How about adding a checkbox to the settings, that says “I know what I’m doing”? (Or perhaps “I don’t drool on myself and can tie my own shoes” 😉
    It would only toggle the “well-known” handling. (Oh well, it could also just be called that. :)))

    Then again, I did just disable it on my server too …

    I guess the actual question was: What is the correct way to access group resources via DAVdroid? There must be a way with well-know URLs enabled. It feels like my server is misconfigured…

  • developer

    Please give a detailed overview of what you’re trying to do. What should the principal path be? Please tell me about the various paths and how they’re related together.

  • Okay. Feel free to not reply if not interested. 🙂

    Well, as I said:

    1. I have multiple users.
    2. The users are in a group.
    3. Each user has at least one calendar and one address book.
    4. The group also has a calendar and a address book.
    5. Since each user is in the group, he should see the group resources too. (The rights are set accordingly, and it works for KDE and Thunderbird.)

    The paths are defined by DAViCal in this pattern:
    which I guess is standardized… (?)

    Now I create the user account on the phone, using the path
    with the user name $user and the correct password.

    But due to the well-known URLs, I assume
    should suffice.

    What I (as a n00b) then expect to happen in DAVdroid, is to get shown a list of all calendars, contacts (and eventually tasks) to which the user has access. I assume this would perhaps be created in the following way:

    getResources(loggedInUser, [])
    function getResources(principal, trace) {
        if (principal in trace) { warning "Infinite loop!"; return [] }; trace += principal
        availableResources = principal.resources.filter({ access = allowed })
        for each (group in principal.groups) { availableResources += getResources(group, trace) }
        return availableResources

    This still ignores the possibility of resources that have no connection to a user still being accessible to a user. So maybe it would be even better to also offer a (series of) free text field(s) instead of just radio/check boxes, so one could add arbitrary paths…

    Now the problem is, that that is all just how I guess it might work… in my head,
    and I have no idea how this whole thing was intended to work,
    or if this is even part of any RFC or just the way DAViCal works…

    And I really would like to configure everything “the right way”. Including well-know URLs.
    Because what I do now either requires disabling well-known URLs and using a specific URL…
    or will leave the group resources not accessible at all.

    Both don’t sound like “the right way”, and I feel like I have not understood how this is meant to be configured and used at all.

Similar topics