Feature request: ability to repeat from completion date #1730

New Issue

tpansino · 2020-06-11T22:27:43Z

tpansino commented

2020-06-11 22:27:43 +00:00

As a user, I want to be able to set up recurring tasks that repeat from the current date when marking the task complete (rather than the due date), so that I can schedule things like recurring maintenance tasks, chores, and other tasks which only need to be due a specific amount of time after the previous completion.

Examples:

A laundry task which repeats every 2 weeks after completion date
A task reminder to get an oil change every 6 months

Examples of tools with similar features: Todoist, Omnifocus

As a user, I want to be able to set up recurring tasks that repeat from the current date when marking the task complete (rather than the due date), so that I can schedule things like recurring maintenance tasks, chores, and other tasks which only need to be due a specific amount of time after the previous completion. Examples: * A laundry task which repeats every 2 weeks after completion date * A task reminder to get an oil change every 6 months Examples of tools with similar features: Todoist, Omnifocus

adrinux commented

2020-06-11 22:43:49 +00:00

I have repeating daily backup tasks for the household computers, but don't always backup each one every day because some days they don't get used. Currently those tasks are all saying 'due 1 month ago' or similar despite the fact that I ran backups and checked them all off. All that happens is the due date is reduced by one day.

I don't particularly like the way Todoist does repeating tasks though, where the 'repetition' is a property of the task - ended up deleting the repeating task instead an instance I wanted to skip.

I prefer the idea of repeating task 'generators'. Where a generator creates a single instance of a task on a repeating basis.

I have repeating daily backup tasks for the household computers, but don't always backup each one every day because some days they don't get used. Currently those tasks are all saying 'due 1 month ago' or similar despite the fact that I ran backups and checked them all off. All that happens is the due date is reduced by one day. I don't particularly like the way Todoist does repeating tasks though, where the 'repetition' is a property of the task - ended up deleting the repeating task instead an instance I wanted to skip. I prefer the idea of repeating task 'generators'. Where a generator creates a single instance of a task on a repeating basis.

tpansino commented

2020-06-11 22:51:39 +00:00

I prefer the idea of repeating task ‘generators’. Where a generator creates a single instance of a task on a repeating basis.

I'm a bit confused - isn't this how Todoist does it?

ended up deleting the repeating task instead an instance I wanted to skip.

Whenever I've wanted to skip a recurring task of this kind in Todoist I just check it off, which marks the existing task instance complete and creates a duplicate instance with the due date set to the current date + the repeat period.

The only downside I've seen to this strategy is that it interferes with Todoist's productivity score, but Vikunja doesn't currently have that.

Could also create a "Skip" button option, in addition to "Mark completed", to enable what you're describing.

> I prefer the idea of repeating task ‘generators’. Where a generator creates a single instance of a task on a repeating basis. I'm a bit confused - isn't this how Todoist does it? > ended up deleting the repeating task instead an instance I wanted to skip. Whenever I've wanted to skip a recurring task of this kind in Todoist I just check it off, which marks the existing task instance complete and creates a duplicate instance with the due date set to the current date + the repeat period. The only downside I've seen to this strategy is that it interferes with Todoist's productivity score, but Vikunja doesn't currently have that. Could also create a "Skip" button option, in addition to "Mark completed", to enable what you're describing.

adrinux commented

2020-06-12 10:03:09 +00:00

isn’t this how Todoist does it?

No, it works in the the way Vikunja currently appears too (I'm not a dev, just a user), with the repeat 'metadata' attached to the task itself.

What I'm describing is like Things.app on OSX - a good few years ago now, no idea whether it still works this way - where there was a seperate UI space to set up repeating tasks, but a specific instance of a repeating task just appeared in whatever list/category etc you specified when it gets generated.

I just check it off, which marks the existing task instance complete

Yep, because todoist has that 'repeat when complete' setting.

I was agreeing that Vikunja needs something similar, just suggesting that I don't particularly like Todoists approach because I ended up deleting repeating tasks by accident - but maybe that's just because I had several years of Things.app use before that.

> isn’t this how Todoist does it? No, it works in the the way Vikunja currently appears too (I'm not a dev, just a user), with the repeat 'metadata' attached to the task itself. What I'm describing is like Things.app on OSX - a good few years ago now, no idea whether it still works this way - where there was a seperate UI space to set up repeating tasks, but a specific instance of a repeating task just appeared in whatever list/category etc you specified when it gets generated. > I just check it off, which marks the existing task instance complete Yep, because todoist has that 'repeat when complete' setting. I was agreeing that Vikunja needs something similar, just suggesting that I don't particularly like Todoists approach because I ended up deleting repeating tasks by accident - but maybe that's just because I had several years of Things.app use before that.

konrad commented

2020-06-12 11:40:40 +00:00

Currently, Vikunja will add the recurring interval to everything and mark the task as undone if it gets marked as done and has a reccurring interval.

So, in theory, what you want to do is already possible.

However, I understand the problem as mentioned by adrinux that there may be tasks one does not do that often and therefore the due date etc. is merely increased by the reccurring interval which means a lot of marking the task as done until it is really done.

I think a good solution to this would be to check whenever a reccurring task is marked as done if the new calculated due date is still in the past. If that would be the case, increase the due date by adding the interval until the new due date is in the future.
I'm just not sure what to do with the other attributes like reminders, start + end dates etc. Maybe these should just be increased as well in these cases.

@adrinux Is that what you meant by "repeat when complete"?

I think this is pretty much this:

Whenever I’ve wanted to skip a recurring task of this kind in Todoist I just check it off, which marks the existing task instance complete and creates a duplicate instance with the due date set to the current date + the repeat period.

Currently, Vikunja will add the recurring interval to everything and mark the task as undone if it gets marked as done and has a reccurring interval. So, in theory, what you want to do is already possible. However, I understand the problem as mentioned by adrinux that there may be tasks one does not do that often and therefore the due date etc. is merely increased by the reccurring interval which means a lot of marking the task as done until it is really done. I think a good solution to this would be to check whenever a reccurring task is marked as done if the new calculated due date is still in the past. If that would be the case, increase the due date by adding the interval until the new due date is in the future. I'm just not sure what to do with the other attributes like reminders, start + end dates etc. Maybe these should just be increased as well in these cases. @adrinux Is that what you meant by "repeat when complete"? I think this is pretty much this: > Whenever I’ve wanted to skip a recurring task of this kind in Todoist I just check it off, which marks the existing task instance complete and creates a duplicate instance with the due date set to the current date + the repeat period.

👍 1

worldworm commented

2020-06-12 12:12:39 +00:00

I think this is a think which is depending on the task. So i think it would be greate if you have a checkbox that appears when the repeating interval is activated where you can change if duedate + repeatinginterval OR today + repeatinginterval

Example:
Wash Car -> Always today + interval
Pay Monthly Bills -> Always Duedate + interval

But having the mentioned button so you dont have to click the done button too many times if there is a Duedate + interval task would be great as well!

I think this is a think which is depending on the task. So i think it would be greate if you have a checkbox that appears when the repeating interval is activated where you can change if duedate + repeatinginterval OR today + repeatinginterval Example: Wash Car -> Always today + interval Pay Monthly Bills -> Always Duedate + interval But having the mentioned button so you dont have to click the done button too many times if there is a Duedate + interval task would be great as well!

konrad added the

kind/feature

label 2020-06-12 15:16:01 +00:00

tpansino commented

2020-06-12 17:09:30 +00:00

So I'm hearing a second user story, which is:

"As a user, when I mark a repeating task as completed, I want the new due date to always be some date in the future (calculated by adding repeat intervals until the new date is > now), so that tasks like paying bills which are tied to a specific date update properly."

This is great, but not what I want this ticket to focus on. This second story has a workaround - you can just tap Done until the due date is in the future, which for something like a bill usually isn't more than an extra tap or two.

The original story doesn't have a similar workaround, you'd have to update the due date yourself to be 2 weeks from today, which requires doing date math in your head, often across months (vomits), hence my request.

I'll file the second story as another ticket, and if the devs want to combine the two that's fine.

So I'm hearing a second user story, which is: "As a user, when I mark a repeating task as completed, I want the new due date to always be some date in the future (calculated by adding repeat intervals until the new date is > now), so that tasks like paying bills which are tied to a specific date update properly." This is great, but not what I want this ticket to focus on. This second story has a workaround - you can just tap Done until the due date is in the future, which for something like a bill usually isn't more than an extra tap or two. The original story doesn't have a similar workaround, you'd have to update the due date yourself to be 2 weeks from today, which requires doing date math in your head, often across months (_vomits_), hence my request. I'll file the second story as another ticket, and if the devs want to combine the two that's fine.

👍 1

tpansino referenced this issue from vikunja/frontend

2020-06-12 17:11:33 +00:00

Feature request: repeating tasks should always repeat in the future #1731

konrad commented

2020-06-12 18:18:18 +00:00

I think to support both cases we'd need an extra flag - We can't implicitly support both cases. The extra flag would be something that the user would need to implicitly set when setting a repeating interval for the task.
I'd like to make the other one (#155) the default one because I think it is the more intuitive one.

I really like you're submitting the feature requests as user stories! That's something not many PMs I work with are capable of...

I think to support both cases we'd need an extra flag - We can't implicitly support both cases. The extra flag would be something that the user would need to implicitly set when setting a repeating interval for the task. I'd like to make the other one (#155) the default one because I think it is the more intuitive one. I really like you're submitting the feature requests as user stories! That's something not many PMs I work with are capable of...

tpansino commented

2020-06-12 20:09:26 +00:00

I really like you’re submitting the feature requests as user stories! That’s something not many PMs I work with are capable of...

Thanks, I'm just a lowly DevOps/Backend engineer with past scars from lack of clear communication :)

I think to support both cases we’d need an extra flag

+1 this as a backend dev. I imagine this will take an API change too, but a new flag (or an enum?) is the right way to model the data IMO.

I’d like to make the other one (#155) the default one

Do you mean "I'd like the story in 155 to be the default behavior for repeating tasks" or "I'd like to close out this 152 ticket in favor of 155"? I'm assuming the first.

> I really like you’re submitting the feature requests as user stories! That’s something not many PMs I work with are capable of... Thanks, I'm just a lowly DevOps/Backend engineer with past scars from lack of clear communication :) > I think to support both cases we’d need an extra flag +1 this as a backend dev. I imagine this will take an API change too, but a new flag (or an enum?) is the right way to model the data IMO. > I’d like to make the other one (#155) the default one Do you mean "I'd like the story in 155 to be the default behavior for repeating tasks" or "I'd like to close out this 152 ticket in favor of 155"? I'm assuming the first.

konrad commented

2020-06-12 21:37:21 +00:00

I imagine this will take an API change too, but a new flag (or an enum?) is the right way to model the data IMO.

Yup, both issues actually need to be solved on the api side rather than in the frontend :)

I will probably add an extra field to the task model.

Do you mean “I’d like the story in 155 to be the default behavior for repeating tasks”

Yes, exactly. I think that feels more natural (as in, does not look like a breaking change despite being one).
I'll probably implement #155 before this one though.

> I imagine this will take an API change too, but a new flag (or an enum?) is the right way to model the data IMO. Yup, both issues actually need to be solved on the api side rather than in the frontend :) I will probably add an extra field to the task model. > Do you mean “I’d like the story in 155 to be the default behavior for repeating tasks” Yes, exactly. I think that feels more natural (as in, does not look like a breaking change despite being one). I'll probably implement #155 before this one though.

konrad referenced this issue

2020-06-14 09:56:12 +00:00

Repeat tasks after completion #587

konrad commented

2020-06-14 11:05:33 +00:00

The api is now capable of this (47d7e713af). Next up is the frontend part.

The api is now capable of this (https://kolaente.dev/vikunja/api/commit/47d7e713af4d72c1441b7a22e654e6cf88ed34c8). Next up is the frontend part.

konrad commented

2020-06-14 12:44:50 +00:00

The frontend part is implemented in 366c469843.

Since this is now fully implemented, I'll close this issue. Feel free to reopen.

The frontend part is implemented in https://kolaente.dev/vikunja/frontend/commit/366c469843b1a7bb4d952ce17f0dfd666a769ecc. Since this is now fully implemented, I'll close this issue. Feel free to reopen.

konrad closed this issue

2020-06-14 12:44:51 +00:00

konrad referenced this issue from a commit

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

chore(deps): update dependency caniuse-lite to v1.0.30001322 (#1730)

Sign in to join this conversation.