Should be fixed with commit 329ab80e62e87867cbdd25da4ba75fb5117da050 (disable strict parsing instead of adding the lang attribute, because we don’t use it and there might be other unknown properties)
DAVdroid tries to write to write protected addressbook
@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
- address books marked as read-only by the server are treated as read-only by the client
- address books marked as read/write by the server can (optionally) be treated as read-only by the client (there is a configuration option called “one-way sync”)
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
- a new account type “DAVdroid address book” (until now: only “DAVdroid”, which makes the whole thing quite simple, which was the intention behind this design decision)
- every synced CardDAV collection is assigned to a local “DAVdroid address book account” (allows multiple address books per DAVdroid account, because for Android, there are multiple accounts)
- sync of “DAVdroid address book accounts” is still managed by the DAVdroid account (contacts sync of DAVdroid account enumerates all address book accounts and syncs the collections)
- read-only CardDAV collections are assigned to yet another account type “DAVdroid read-only address book account” which doesn’t have an XML scheme for editing, so entries can’t be edited with the Contacts app
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