Thanks for the information and update! Great that you found it out.
Sorry for the inconvenience. Now we know that no_script prevents the usage of the forum. We’ll have a look at it.
I deleted a calendar on the server but this is not been recognized with DAVdroid.
Related to #219.
What do you think would be an appropriate reaction of DAVdroid? To delete the calendar locally, too? What if there’s just a temporary problem with the server – would it be OK to delete the local calendars then?
To be honest, the problem of how to manage adding/deleting various collections of an existing account is not solved yet. Do you have suggestions?
The biggest problem is, that it looks like that the sync is failing. So when DAVdroid can’t find one calendar but all other it should mark the calendar accordingly as not found or something. If it can’t find the same calendar the next round it should be marked silent, and after the next round DAVdroid should assume the calendar is gone and delete it locally.
Maybe not perfect. But it is better to mark the sync failing. And present the calendar as if it is still there, even though I just deleted it.
I know this is old, but I think deleting the calendar locally (at least without prompting the user first) is not the way to go because it could lead to permanent data loss if the server and its data disappeared.
Partially agree with @tehabe: Mark it not found (internally), issue a notification, and when the user opens that give the possibility to delete or ignore. The user should know whether it’s gone, so when (s)he decides it can be deleted, so it is.
At the same time: If the “missing calender” is selected to add an entry to, issue a warning (“currently not available/cannot be synced. Add anyway?”). Thus even with the notification missed, there’s another one to “wake up the user”
I agree with @IzzySoft
I am not sure if the common implementations of the CalDAV and CardDAV standards allow for a fine distinction between something like permission problems and the calendar being gone.
@untitaker I’m not 100% sure (as that might depend on implementation) – but shouldn’t a permission denied issue an 403 (forbidden), while a non-existing page should give a 404 (not found) or 410 (gone)? After all, CalDAV and CardDAV are extensions to WebDAV, which is an extension to HTTP
The spec isn’t ambiguous, but implementors don’t need to care about it