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.
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?
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?
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.
Reminders are not exported as CALDAV attributes and thus do not appear on mobile clients.
Alarms from CALDAV clients are ignored.
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.
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?
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?
That is true. I don't think it is safe.
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.