Since updating to DAVdroid 1.0+, shared calendars subscribed by user accounts seem to be appearing twice in the calendars field. By looking at the debugging information it seems that the homeset of the owner of the shared calendar is being added causing the additional calendars to appear.
In this example user1 is subscribed to a calendar shared by user2 which is shared to all authenticated users… User1’s credentials are used to log in to DAVdroid and the following debugging information was created.
http://fpaste.org/349188/45974063/
This behaviour was not present in DAVdroid 0.9xx where only the subscribed instance of the calendar (under user1’s account) was shown.
Anyone else seen this issue?
@silkyriver said:
This behaviour was not present in DAVdroid 0.9xx where only the subscribed instance of the calendar (under user1’s account) was shown.
Yes, DAVdroid 0.9.x had a far less powerful resource detection, especially for shared calendars.
By looking at the debugging information it seems that the homeset of the owner of the shared calendar is being added causing the additional calendars to appear.
Indeed. The reason why you see the shared calendars multiple times is because they’re available multiple times:
https://example.com/SOGo/dav/user2/Calendar/68D-xxxxxxxx-1-xxxxxxxx/https://example.com/SOGo/dav/user1/Calendar/user2_68D-xxxxxxxx-1-xxxxxxxx/So, the calendars have different URLs, so they’re shown twice: one time it’s the shared (and detected) calendar of user2, and one time it’s the “imported” calendar of user2 into the homeset of user1.
In SoGO, there’s a “subscribe” checkbox when you share calendars. I don’t know whether it’s related to this.
Do you see any problem? Where’s the “issue”? Two calendars (with two different URLs) are available, two calendars are shown.
@rfc2822 said:
Do you see any problem? Where’s the “issue”? Two calendars (with two different URLs) are available, two calendars are shown.
The issue in my particular usage is that DAVdroid behaviour is inconsistent with other CardDAV/CalDAV clients in use. For example, with CalDAV Synchronizer (Outlook client that does both CalDAV and CardDAV despite its name) and iOS, when authenticated as user1 it will only allow you to view data that is available under user1’s account. For this reason after user2’s calendar is shared to all users, user1 will still need to “subscribe” which adds user2’s calendar as a synced copy into user1’s account. This allows other CalDAV clients to view user2’s calendar using user1’s credentials.
It also seems that the CardDAV component of DAVdroid acts in this manner. When user2’s address book is shared to all users, it does not appear under available address books when logged into DAVdroid using user1’s credentials. When user1 “subscribes” to user2’s address book within SOGo then user2’s address book is shown in DAVdroid.
I do not have much experience with WebDAV servers/clients, and my experience is limited with SOGo, so I don’t know how the other servers handle sharing of calendars/contacts, but in my environment it seems that the DAVdroid 0.9.x behaviour made more sense.
The other thing with having the two copies of the same calendar (one from user2, one from user1’s subscription) is that although the url’s are different, they have the same name. Functionally it doesn’t matter which one you select within DAVdroid as they are effectively the same calendar, but it is quite confusing.
I can see that you consider this to be an upgraded feature to the previous behaviour in DAVdroid 0.9.x, and in some usage cases it certainly would be. It would eliminate the need to “subscribe” to the calendars under user1’s account for them to see user2’s calendar. However it could get very confusing and possibly expensive? if many users have globally shared calendars, which would be shown in each user’s list. Perhaps if there was an option to disable this feature to switch behaviour back to the way it was in DAVdroid 0.9.x then it would make it more user friendly? (I’m not a programmer so please don’t bash me if I’m making an outrageous suggestion…)
It’s nice that DAVdroid offers all found calendar URLs, but that is not the right way to do it.
You should either filter for duplicate calendar ID’s, or create a configurable option to look only for subscribed or all available calendars.
@winterth said:
It’s nice that DAVdroid offers all found calendar URLs, but that is not the right way to do it.
Nice to hear your opinion, but could you please explain why?
@rfc2822
You should either filter for duplicate calendar ID’s
Which kind of “ID” do you mean? In my opinion, a calendar’s ID is its URL (and as far as I know, there are no further “IDs” in CalDAV) – and DAVdroid filters duplicate URLs.
or create a configurable option to look only for subscribed or all available calendars.
As far as I know, there’s no way to distinguish between “subscribed” or “available” calendars? How should that work? In CalDAV, there are only calendars, and they can be detected and that’s it.
@rfc2822
You should either filter for duplicate calendar ID’sWhich kind of “ID” do you mean? In my opinion, a calendar’s ID is its URL (and as far as I know, there are no further “IDs” in CalDAV) – and DAVdroid filters duplicate URLs.
or create a configurable option to look only for subscribed or all available calendars.
As far as I know, there’s no way to distinguish between “subscribed” or “available” calendars? How should that work? In CalDAV, there are only calendars, and they can be detected and that’s it.
I see that you rely on the CalDAV protocol but the point I’m trying to make is that it’s not all about sticking to the standard. You get a better application by offering a simple and comfortable user experience.
It is nice to have an application that finds all available calendars for a user but it is even better for the USER to have an option like the one I described above. Other CalDAV applications maybe don’t look for all available calendars but only the actually subscribed ones (like you did in version 0.9 ?). The use-case of subscribing to different calendars on a mobile device then on a desktop computer is very little. So in my opinion the default would be best to only show subscribed calendars and by changing a setting the user can have access and subscribe to one of the other available calendars.
Please let me know if there is no intention in improving this issue. Then I will change our DAVdroid instructions so the users are aware of it.
@winterth said:
I see that you rely on the CalDAV protocol but the point I’m trying to make is that it’s not all about sticking to the standard. You get a better application by offering a simple and comfortable user experience.
Relying on the CalDAV protocol is not in contrast to having a comfortable user experience.
Other CalDAV applications maybe don’t look for all available calendars but only the actually subscribed ones (like you did in version 0.9 ?). […] the default would be best to only show subscribed calendars and by changing a setting the user can have access and subscribe to one of the other available calendars.
As said before, there is no such thing as “subscribed calendars” in CalDAV. It’s simply not possible for DAVdroid to distinguish between “subscribed” and “non-subscribed” calendars. There are just calendars.
The only difference between 0.9 and 1.0 is that 1.0 uses more methods to detect calendars, and in your case is able to detect more calendars.
So, I can’t see any “issue” here, except that your server offers the same calendar multiple times with different URLs. If you have specific technical suggestions about how to improve resource detection, please let us know.
Ok, got it. Thanks for the detailed reply.
One last thing I didn’t find a matching thread for:
The only difference between 0.9 and 1.0 is that 1.0 uses more methods to detect calendars, and in your case is able to detect more calendars.
Did the resource detection for Address Books got improved too? I was testing with the latest DAVdroid Version 1.0.7 and besides my personal Address Books, no shared Address Books were detected. Only after subscribing to them through the SOGo webinterface they were detected by DAVdroid. Is this a known limitation or do you have a related thread for me?
@winterth said in Duplicated Shared Calendars:
I was testing with the latest DAVdroid Version 1.0.7 and besides my personal Address Books, no shared Address Books were detected. Only after subscribing to them through the SOGo webinterface they were detected by DAVdroid. Is this a known limitation or do you have a related thread for me?
This is the same inconsistent behaviour as I’ve found in which DAVdroid handles contacts and calendars. It’s quite confusing that for calendars, it’s enough to have share permissions to view/modify the calendar in order for it to show up in your available calendars, but for contacts you must “subscribe” for the shared address book to be available to the user.
@rfc2822 said in Duplicated Shared Calendars:
The only difference between 0.9 and 1.0 is that 1.0 uses more methods to detect calendars, and in your case is able to detect more calendars.
This may be very much the case and that DAVdroid is superior to other software (i.e. iOS, CalDAV Synchronizer ) in finding calendars available to the user, but if it isn’t consistent with other software, it makes it very difficult to deploy in a multi-user, multi-OS environment. The other software mentioned will behave like DAVdroid 0.9, so users must “subscribe” to the calendar for other non-DAVdroid applications to see the shared calendars.
It may be a particular quirk of the environment that I am using; I am interested to know what WebDAV server @winterth is using.
@silkyriver said in Duplicated Shared Calendars:
This is the same inconsistent behaviour as I’ve found in which DAVdroid handles contacts and calendars. It’s quite confusing that for calendars, it’s enough to have share permissions to view/modify the calendar in order for it to show up in your available calendars, but for contacts you must “subscribe” for the shared address book to be available to the user.
Maybe it’s because there is are (proposed, but often used) standard for detecting shared calendars using calendar-proxy-read/write (which is used by DAVdroid), but there’s no such standard for address books. If this is the method how your shared calendars are detected, shared addressbooks can’t be detected the same way.
Technical details would be really helpful for deeper insights.