I have encounter this problem once again, I have reported it to nextcloud community (https://github.com/nextcloud/server/issues/6657)
Using DAVdroid 184.108.40.206-ose from F-Droid with ownCloud 9.1.4 (stable). One of the ownCloud calendars is shared with an other user but just read-only. That user is using that shared read-only calendar on an Android 7.0 phone using DAVdroid. DAVdroid recognized this calendar correctly as read-only by displaying the correct symbol on the account.
User do have two cards for one person on two different calendars (linked to each other). One of the calendars is read-write, the other one is the read-only calendar described above.
After user called a number from this card, some data should be written to the card (see issue 1290). My guess would be that this should be written just to the card of the read-write calendar, but DAVdroid also tries to write it to the read-only calendar.
So with every sync, users gets an error message mentioning DAVdroid can’t write to the read-only calendar.
This is a known problem. Unfortunately, I don’t know a possibility how to tell Android certain address books are read-only. If know know a way to accomplish that, please let us know.
Thanks a lot for the quick reply.
I do not know enough about Android and the design of DAVdroid, but isn’t there a way for DAVdroid to check if a calendar is read-only and filter out all write requests to it?
@Holgi Now I’m confused because I have read “address book” in your title, but now we’re talking about calendars.
Is it about address books or calendars?
Concerning calendars, DAVdroid already sets read-only CalDAV calendars (which are shown as read-only in DAVdroid) to read-only in the Android calendar storage, so calendar apps can’t make changes (with works with the tested calendar apps).
Address books and calendars are implemented very differently in Android and are not related to each other. Can you please provide verbose steps to reproduce your problem (including all involved software and details)?
Sorry, I was confusing calendars with address books in both of my comments. 8-) Sorry for the confusion.
All I described and suggested was just related to address books.
I see. As said before, I don’t know a usable solution for address books.
If someone finds one some day, let us know.
Maybe one of your developers could contact Marten Gajda (firstname.lastname@example.org) who is the developer of CardDAV-Sync, CalDAV-Sync and find out how he solved the issue with read-only address books on Android? CardDAV-Sync even offers a client-configuration option to treat a read/write address book as read-only, so
It’s really a shame that DAVdroid can’t treat address books as read-only as this is THE major obstacle to rolling out DAVdroid in a corporoate environment: any change to a contact of a read-only address book breaks the sync account (error messages) and in many cases the user cannot even be blamed for changing the contact as there are many use cases on an Android device that cause contact data to change (e.g. marking a contact as favorite in the phone book, merging contacts from different sync accounts, etc.)
@cmu You can of course contact Marten Gajda and post the solution here. We will then think about implementing it if it’s not too hacky.
I think the read-only mode is not that hard to implement. When fetching data from server, as well as serving one copy for Android to use, keep another copy internally. When addressbook provider receives local changes, don’t push changes to server, and use the internal copy to revert local changes.
I am not an Android dev, so I don’t know this is practical at all.
as a first measure (IMHO) you should do the following client-side:
if an address book is marked as read-only you do NOT upsync any contacts to the server EVER (as long as you cannot lock down the address book locally on the Android device, this will obviously lead to differences between the server and the client if a contact of such an address book is changed on the client, but at least this does not break the sync account)
(and I’ll try to find out from Marten how he solved the issue)
Such behavior would inevitably result in an endless stream of bug reports like “DAVdroid reverting changes to local address book. Why?? Error, fix!!1!”
I don’t think this is a good idea, especially because it breaks the whole sync logic and is a dirty hack and creates behavior which can’t be understood by users. For instance, take a read-only file system: it doesn’t allow write access and then magically reverts all written data. Such behavior would cause a lot of inconsistent information, application errors and user muzz. Instead, write operations must not be allowed and result in an error. In my current opinion, no support for read-only address books is better than such a solution.
It could be possible with other account types (which don’t have an edit XML scheme for contacts), but this would require a complete change of the way how DAVdroid works and its sync logic, too…
I guess it could be solved with
Theoretically, this could work (and bring multiple address books per DAVdroid account, too), but of course it would need a rewrite of large core parts of DAVdroid (and cause an uncountable number of bugs in the first year). And we don’t even have beta testers who are actually willing to test…
BTW, shouldn’t *DAV-Sync be open-source in the meanwhile?
I don’t think this is a good idea, especially because it breaks the whole sync logic and is a dirty hack and creates behavior which can’t be understood by users.
no problem - our users (corporate users connecting to openCRX) are actually more disturbed by the fact that the sync process breaks because of the various 403-Forbidden messages - as long as an address book (or it’s contacts, respectively) cannot be locked down properly if a collection is marked as read-only, it’s just a matter of time until the client doesn’t sync anymore because the user (or some other app running on the device) has made changes to a contact…
anyway, we have adapted the behavior on the server-side such that DAVdroid does not receive 403-Forbidden anymore - the server claims to accept the create- or update-request but actually ignores it and ensures that any (forbidden) changes on the Android devices are simply undone with the next sync (from the admin’s perspective it’s much better to annoy/educate the user than to break the sync account)
and ideally Android gets it’s act together and supports read-only contacts and/or address books