Error adding reminder to a read-only calendar (Fastmail)

[projectgus]

I have encountered a minor problem using DAVx5 with Fastmail. Happy to work on a fix and submit a PR, but I was hoping to get some guidance first as I'm a CalDAV newbie.

Setup

• I'm using Fastmail with CalDAV
• Fastmail allows you to add "Subscriptions" to external iCal feeds that it then exports via CalDAV as read-only calendars.
• Fastmail doesn't allow attaching reminders to these calendar items in the Fastmail calendar interface
• Android Calendar does allow attaching reminders to these items (which is useful!)

Problem I'm Seeing

1. In Fastmail, add one of these "Subscriptions" to an external calendar
2. Sync the new calendar to Android via DAVx5
3. In Android Calendar (I'm using "etar" AOSP calendar fork), add a Reminder to one of the calendar items
4. Notification pops up "HTTP server error - HTTP 403 Forbidden" and the notification repeats each time DAVx5 tries to sync the calendar, until the reminder is removed or the remote calendar entry updates.

Specifically, when DAVX5 sends the update request with a new VALARM then Fastmail replies with HTTP 403 and no response body. DAVx5 SyncManager already ignores 403 responses if the Error.NEED_PRIVILEGES flag is set in the response, but in this case it's not set (I think rightly so, as we have privileges but this particular calendar is not writable.)

Possible Fix 1

The simplest fix I can think of would be not to queue any update events for read-only calendars. However, I don't know if other CalDAV servers might have read-only calendars that do accept updates to only set VALARMs - is that possible?

Possible Fix 2

Ignore any 403 exception if we try to update a calendar that we know is read-only. This allows for the possibility of supporting a "VALARM updates only" CalDAV server, if such a thing exists. I have a branch with this change, here: dev-ose...projectgus:davx5-ose:bugfix/reminders_read_only_calendar

Remaining Problem

With either of these fixes, there's of course still a problem: even if DAVx5 ignores the update failure, any future server-side update to the calendar entry will override the local state and silently erase the reminders. Which is not great...

The only fix I can think of would be to flag the reminder entries in the local database as "local only", and retain any "local only" reminders when updating from the server.

But this seems fiddly, so I wanted to ask here before looking further into it. If there's any approach that you think could be acceptable, I'm happy to work on it and submit a PR.

Thanks!

[rfc2822]

Hello,

Thanks for your report. This is a known problem (internal reference: bitfireAT/davx5#54), and as you have already written, the possible solutions are not easy and all have side effects.

I think your solution 1 (don't upload modified events when they come from a read-only calendar) would be the best one. But as you say, such events would be overwritten when they're updated on the server. The "local only" indeed sounds hacky… maybe there could be some local extended property ("custom alarm") for this problem, but it's all not that easy.

[projectgus]

@rfc2822 Thanks very much for the update and letting me know your perspective on this.

I'll have more of a think about it and see if I can come up with a draft PR for further discussion.

[dilyanpalauzov]

This is a problem of eTar. It shall not permit adding a reminder to read-only event/calendar.

[rfc2822]

Are you sure? As I understand it, there's no explicit rule in Android that this is not allowed for read-only calendars; and it's useful for users who want to be reminded for a read-only event.

[dilyanpalauzov]

The 'Google Calendar' on Android does not allow adding reminders to events on read-only calendars.

[rfc2822]

But the Google Calendar doesn't define a standard or something (and Google apps tend to change behavior regularly, see the Contacts app). The calendar provider allows setting alarms for events in read-only calendars and so calendar apps/people will use it.

And as said before, I think it's a valid use-case for people and so we should think how to make it working.

However due its complexity it will surely take some time.

[dilyanpalauzov]

I think it's a valid use-case for people and so we should think how to make it working.

One way is to duplicate (clone) the event to a different calendar and modify the copy, e.g. by adding reminders.

[dilyanpalauzov]

See also Etar-Group/Etar-Calendar#523.

[dilyanpalauzov]

I have today a different, similar problem. I synchronize one way the tasks and events from server aegee.org without username, without password over DAVx⁵ to Tasks.org. I synchorize the Events and Tasks, I do not synchorize the address data . The source is read-only, Tasks does not have the notion of read-only tasks list.

Apparently Tasks.org has modified somehow a task. I would say this was done by the app automatically, but even if the user (me) has changed a VTODO implicitly, this does not change the following problem. I doubt I have changed anything manually, since I have Tasks.org+DAVx⁵ on two phones and both phones started today suddenly at the same time to complain.

DAVx⁵ calls PUT for a task and the server reject it with

2022-07-18 12:42:32 1145 [HttpClient] <-- 401 https://cal.aegee.org/dav/calendars/user/cal/OMS/e947872a-224b-4c84-8d25-90a541a9ec4a-47.\
ics (113ms)
2022-07-18 12:42:32 1145 [HttpClient] date: Mon, 18 Jul 2022 09:42:32 GMT
2022-07-18 12:42:32 1145 [HttpClient] content-type: text/html; charset=utf-8
2022-07-18 12:42:32 1145 [HttpClient] content-length: 356
2022-07-18 12:42:32 1145 [HttpClient] cache-control: no-cache
2022-07-18 12:42:32 1145 [HttpClient] www-authenticate: Negotiate
2022-07-18 12:42:32 1145 [HttpClient] www-authenticate: Basic realm="aegee.org"
2022-07-18 12:42:32 1145 [HttpClient] content-encoding: gzip
2022-07-18 12:42:32 1145 [HttpClient]

It is also reproducible: I delete all accounts from DAVx⁵ and all tasks from Tasks.org. Then I set DAVx⁵ to synchorize with Tasks.org and register account for domain aegee.org without username, without password. I fetch the collection names. Then I synchronize the events and tasks (no vCards). During the synchronization DAVx⁵ shows errors. I cannot confirm, that these are 401-errors, as the phone where I do the experiment is pretty new and I cannot fetch the detailed log from it. But I assume it is the 401-error as above.

That said it would be better, if the authentication-error notifications contain more information on which resource what exactly failed.

• Whatever happens DAVx⁵ shall not call PUT towards read-only sources and provide authentication-errors to the user.

DAVx5 4.2.2. For me it seems that with jtx Board this particular problem does not appear.

[dilyanpalauzov]

I have more information: the server sends to DAVx⁵ the property GEO:45.69845;25.61147. DAVx⁵ 4.2.2 sends this data to Tasks.org 12.7. The latter changes it internally, without user intervention to GEO:45.698921424383336;25.6113875615783. Now there is a modification and DAVx⁵ tries to upload the new GEO-property to the read-only collection.

I guess this is related to tasks/tasks#1667 .

My server handels internally the iCalendar data using libical . It used for the GEO-property to parse the input string and present it internally as float, which float was rendered, when the data was converted to string. Recently this practice was discontinued and libical stores internally the GEO-values as strings — libical/libical#531 . So likely the exact GEO-properties are now transferred over CalDAV. The strings might not be the exact float values, which might cause this problem.