feat(caldav): Sync Reminders / VALARM #1415
konrad
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "ce72/api:1408_caldav_alarms"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Relates to vikunja/api#1408
feat(caldav): Sync Reminders / VALARMto WIP: feat(caldav): Sync Reminders / VALARMSee vikunja/api#1408, vikunja/api#1416
9ff547da16to30c1d698e9WIP: feat(caldav): Sync Reminders / VALARMto feat(caldav): Sync Reminders / VALARM@ -74,2 +62,4 @@type Alarm struct {Time time.TimeDuration time.DurationRelativeTo stringI think this should be a string enum (yes, Go does not have real enums but the const type thing)
ok
@ -133,0 +166,4 @@}case len(property.ICalParameters["RELATED"]) > 0:duration := parseDuration(property.Value)switch property.ICalParameters["RELATED"][0] {Doesn't calDAV have a concept of a due date? And if that's the case, can't we use that as a relative anchor point?
I modified the implementation to follow more closely the CalDav standard
https://icalendar.org/iCalendar-RFC-5545/3-8-6-3-trigger.html
I also took a look at tasks.org CalDav implementation https://github.com/tasks/tasks/blob/main/app/src/main/java/org/tasks/caldav/extensions/VAlarm.kt
Can you please look at it again?
I think this is fine now.
@ -156,0 +217,4 @@var durationRegex = regexp.MustCompile(`([-+])?P([\d\.]+Y)?([\d\.]+M)?([\d\.]+D)?T?([\d\.]+H)?([\d\.]+M)?([\d\.]+?S)?`)// ParseDuration converts a ISO8601 duration into a time.Durationfunc parseDuration(str string) time.Duration {We have this exact function already in the ticktick migration. Can you move this in a general helper function and use the same function in both places?
ok
feat(caldav): Sync Reminders / VALARMto WIP: feat(caldav): Sync Reminders / VALARMWIP: feat(caldav): Sync Reminders / VALARMto feat(caldav): Sync Reminders / VALARM@ -260,0 +207,4 @@case models.ReminderRelationStartDate:caldavalarms += `TRIGGER;RELATED=START:` + makeCalDavDuration(a.Duration)case models.ReminderRelationEndDate, models.ReminderRelationDueDate:Won't this add a reminder relative to the end date when there's a due date but no end date?
Yes, that's intended. CalDav standard does not know RELATED=DUE or something like that. The same is true for the implementation at tasks.org.
According to the standard https://icalendar.org/iCalendar-RFC-5545/3-8-6-3-trigger.html due dates are backed by triggers set relative to "END".
After looking more closely at it, there is maybe an issue in the existing code. The VTODO element does not know DTEND at all. I did not change that, but this implies that we don't need ReminderRelationEndDate (we won't be able to sync it anyway, because clients will ignore it.)
There seems to be room for more cleanup PRs... But I think the statement you commented is not incorrect by itself.
Okay, that makes sense. Thanks for the explanation.
So if a users sets a reminder to be relative to the end date in the frontend, it will be ignored by the CalDAV clients?
There almost certainly is!
We would serialize this like
The client will most certainly ignore DTEND and the alarm might get lost. If the task additionally has a due_date given in the frontend, the client will relate the trigger to this date, transferred as DUE.
The other direction probably will not happen: clients will never send DTEND (and the parsing code ignores it anyway..)
If they send
DUE=<timestamp>andTRIGGER;RELATED=END:<duration>then we will create a reminder relative to the due date (which might be the 95% scenario).I am looking forward to testing this with tasks.org once it's in the unstable version. Then maybe we need another iteration. And maybe even some edge cases will never work at all, because Vikunjas model and CalDav do not overlap by 100%. I think in part it is tolerable as long as reminders relative to due_date and then to start_date work as expected, and we understand (and document) what's going on.
🥳