Reminders are not synced with caldav alarms #1408

Open
opened 4 weeks ago by ce72 · 4 comments
ce72 commented 4 weeks ago

Reminders are not exported as CALDAV attributes and thus do not appear on mobile clients.
Alarms from CALDAV clients are ignored.

Reminders are not exported as CALDAV attributes and thus do not appear on mobile clients. Alarms from CALDAV clients are ignored.
konrad added the kind/feature label 3 weeks ago
ce72 commented 3 weeks ago
Poster

I started working on this issue, but I think it is at least in part blocked by #1416.

Caldav clients can deliver VALERTS which may contain
TRIGGER;VALUE=DATE-TIME:20181201T011210Z
or TRIGGER:-PT60M
or TRIGGER;RELATED=START:-P1D
or TRIGGER;RELATED=END:-PT60M
where only the first one is supported by the current Vikunja model.

I started working on this issue, but I think it is at least in part blocked by https://kolaente.dev/vikunja/api/issues/1416. Caldav clients can deliver VALERTS which may contain TRIGGER;VALUE=DATE-TIME:20181201T011210Z or TRIGGER:-PT60M or TRIGGER;RELATED=START:-P1D or TRIGGER;RELATED=END:-PT60M where only the first one is supported by the current Vikunja model.
konrad commented 3 weeks ago
Owner

So we either need to implement relative dates in Vikunja first, or recalculate relative caldav dates to absolute dates when they are changed via caldav?

So we either need to implement relative dates in Vikunja first, or recalculate relative caldav dates to absolute dates when they are changed via caldav?
ce72 commented 3 weeks ago
Poster

In fact, I implemented the recalculation to absolute dates in the PR.
But I commented this out, because I don't think it will be a good idea. It would either risk duplicate reminders on the client (the relative and the synced ones) or it could mean that the relative dates will be overwritten. It's hard to predict and probably depends on how the client does the merge. Or do you think it's safe?

But at least the absolute dates from Vikunja could be synced with the absolute dates on the caldav client (supporting TRIGGER;VALUE=DATE-TIME and ignoring others). This should be safe. Do you think we should do that as a temporary solution?

In fact, I implemented the recalculation to absolute dates in the PR. But I commented this out, because I don't think it will be a good idea. It would either risk duplicate reminders on the client (the relative and the synced ones) or it could mean that the relative dates will be overwritten. It's hard to predict and probably depends on how the client does the merge. Or do you think it's safe? But at least the absolute dates from Vikunja could be synced with the absolute dates on the caldav client (supporting TRIGGER;VALUE=DATE-TIME and ignoring others). This should be safe. Do you think we should do that as a temporary solution?
konrad commented 2 weeks ago
Owner

It's hard to predict and probably depends on how the client does the merge. Or do you think it's safe?

That is true. I don't think it is safe.

But at least the absolute dates from Vikunja could be synced with the absolute dates on the caldav client (supporting TRIGGER;VALUE=DATE-TIME and ignoring others). This should be safe. Do you think we should do that as a temporary solution?

Not sure. TBH I think we should just implement relative dates into Vikunja and then use these. That will be more work up front but will be a clean implementation and avoid ripping a version of this implemented now out.
And we can't tell the clients to not use relative dates so people will inevitable complain about how this does not work for all reminders.

> It's hard to predict and probably depends on how the client does the merge. Or do you think it's safe? That is true. I don't think it is safe. > But at least the absolute dates from Vikunja could be synced with the absolute dates on the caldav client (supporting TRIGGER;VALUE=DATE-TIME and ignoring others). This should be safe. Do you think we should do that as a temporary solution? Not sure. TBH I think we should just implement relative dates into Vikunja and then use these. That will be more work up front but will be a clean implementation and avoid ripping a version of this implemented now out. And we can't tell the clients to not use relative dates so people will inevitable complain about how this does not work for all reminders.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/api#1408
Loading…
There is no content yet.