I frequently find myself editing two dates when postponing a task: the due date and the reminder date. While it's nice to have, most of the time I don't need an absolute trigger time, but want to get notified e.g. 1D or 1H before due, whenever it is due.
Todo clients like tasks.org and others allow setting alarms relative to due. Vikunja cannot really serve this data via CALDAV, because it can't store them, see #1408.
I propose to solve this by viewing reminders as objects and not as timestamps. The API could look like:
where only and exactly one of "time", or the relative dates must be given and the other three are null/absent. The duration values could be iso8601 durations or maybe simply seconds or minutes (?). And maybe it is sufficient to add just relativeDue.
This feature could be introduced non-breaking, if the present reminder_dates array would be deprecated and be removed later, after the frontend has been adapted.
It seems like a bigger operation, so it might be a good idea to ask, what do you think. Does it look reasonable, am I missing something, are there other options or related activities?
Two observations:
- I frequently find myself editing two dates when postponing a task: the due date and the reminder date. While it's nice to have, most of the time I don't need an absolute trigger time, but want to get notified e.g. 1D or 1H before due, whenever it is due.
- Todo clients like tasks.org and others allow setting alarms relative to due. Vikunja cannot really serve this data via CALDAV, because it can't store them, see https://kolaente.dev/vikunja/api/issues/1408.
I propose to solve this by viewing reminders as objects and not as timestamps. The API could look like:
```json
reminders:[
{"time": "2023-02-26T14:31:13+01:00",
"relativeDue": null,
"relativeStart": null
"relativeEnd": null
},
{"relativeDue": "-PT1D"},
{"relativeStart": "-PT1H"},
...
]
```
where only and exactly one of "time", or the relative dates must be given and the other three are null/absent. The duration values could be iso8601 durations or maybe simply seconds or minutes (?). And maybe it is sufficient to add just relativeDue.
This feature could be introduced non-breaking, if the present reminder_dates array would be deprecated and be removed later, after the frontend has been adapted.
It seems like a bigger operation, so it might be a good idea to ask, what do you think. Does it look reasonable, am I missing something, are there other options or related activities?
I like the general idea. While I'm not sure about the formst I think it would make sense to align with the relative dates that we currently use in list filters.
I like the general idea. While I'm not sure about the formst I think it would make sense to align with the relative dates that we currently use in list filters.
It would be very easy to use Go durations for the relative amounts here because they are very easy to parse. At least for saving the reminders we should use that or convert it to seconds or something similar. For the input, given how we'll need code to parse calDAV durations anyway it probbaly won't make that much of a difference.
I had something like this in mind:
```json
"reminders": [
{
"amount": "2023-02-26T14:31:13+01:00",
"relative_to": null
},
{
"amount": "-12h",
"relative_to": "due_date"
},
{
"amount": "30d",
"relative_to": "end_date"
}
]
```
It would be very easy to use Go durations for the relative amounts here because they are very easy to parse. At least for saving the reminders we should use that or convert it to seconds or something similar. For the input, given how we'll need code to parse calDAV durations anyway it probbaly won't make that much of a difference.
👍
Maybe seconds would be the best solution then, like in task.RepeatAfter. This is convertible for go and understandable by all clients.
I will try to work on it in the next days.
👍
Maybe seconds would be the best solution then, like in task.RepeatAfter. This is convertible for go and understandable by all clients.
I will try to work on it in the next days.
Two observations:
I propose to solve this by viewing reminders as objects and not as timestamps. The API could look like:
where only and exactly one of "time", or the relative dates must be given and the other three are null/absent. The duration values could be iso8601 durations or maybe simply seconds or minutes (?). And maybe it is sufficient to add just relativeDue.
This feature could be introduced non-breaking, if the present reminder_dates array would be deprecated and be removed later, after the frontend has been adapted.
It seems like a bigger operation, so it might be a good idea to ask, what do you think. Does it look reasonable, am I missing something, are there other options or related activities?
I like the general idea. While I'm not sure about the formst I think it would make sense to align with the relative dates that we currently use in list filters.
The idea is good. I think I'd do the api differently but that's an implementation detail.
If you have some ideas for the API, just put them in. Would be better to make it right from the beginning :-)
I had something like this in mind:
It would be very easy to use Go durations for the relative amounts here because they are very easy to parse. At least for saving the reminders we should use that or convert it to seconds or something similar. For the input, given how we'll need code to parse calDAV durations anyway it probbaly won't make that much of a difference.
👍
Maybe seconds would be the best solution then, like in task.RepeatAfter. This is convertible for go and understandable by all clients.
I will try to work on it in the next days.