Feature: Support for relative reminders #1416

New Issue

ce72 · 2023-03-04T12:43:09Z

ce72 commented

2023-03-04 12:43:09 +00:00

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 vikunja/api#1408.

I propose to solve this by viewing reminders as objects and not as timestamps. The API could look like:

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?

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?

👍 1 🎉 1

ce72 referenced this issue

2023-03-04 12:44:12 +00:00

Reminders are not synced with caldav alarms #1408

ce72 referenced this issue

2023-03-04 12:46:12 +00:00

feat(caldav): Sync Reminders / VALARM #1415

dpschen commented

2023-03-04 13:08:34 +00:00

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.

konrad commented

2023-03-04 13:15:42 +00:00

The idea is good. I think I'd do the api differently but that's an implementation detail.

ce72 commented

2023-03-04 20:56:49 +00:00

If you have some ideas for the API, just put them in. Would be better to make it right from the beginning :-)

konrad commented

2023-03-05 12:30:53 +00:00

I had something like this in mind:

"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.

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.

ce72 commented

2023-03-05 15:11:30 +00:00

👍
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.

🎉 2

ce72 referenced this issue

2023-03-06 08:28:14 +00:00

#1416: Add relative Reminders #1427

konrad referenced this issue from a commit

2023-03-27 20:07:08 +00:00

feat: Add relative Reminders (#1427)

konrad closed this issue

2023-03-27 20:07:08 +00:00

konrad reopened this issue

2023-03-27 20:07:29 +00:00

ce72 commented

2023-03-27 21:39:25 +00:00

Resolved by vikunja/api#1427.

The frontend part is described in vikunja/frontend#3216.

This issue enables the resolution of vikunja/api#1408 CalDav sync of reminders.

Resolved by https://kolaente.dev/vikunja/api/pulls/1427. The frontend part is described in https://kolaente.dev/vikunja/frontend/issues/3216. This issue enables the resolution of https://kolaente.dev/vikunja/api/issues/1408 CalDav sync of reminders.

ce72 closed this issue

2023-03-27 21:39:25 +00:00

konrad referenced this issue from a commit

2024-02-07 14:00:31 +00:00

fix(deps): update dependency @vue/compat to v3.2.28 (#1416)

Sign in to join this conversation.