I’ve gotten several requests for support for repeating tasks would for things like weekly backups, etc. I have this on my list already, but there are problems with it that I haven’t solved from a hierarchical perspective.
There are 2 basic ways to do this:
1. Generate a task for every instance of the repeating occurance. This has the benefit of letting you easily modify a single occurance of the task (add notes, change the date, things like that) but makes it more difficult to make changes to all of the recurring events as a whole (you need to make sure that property hasn’t been modified from the original – if it has you probably don’t want to change it).
2. Generate a single task that is displayed for each occurance. This makes it really easy to modify all of the instances of the recurring task at once, but doesn’t let you make changes to each instance.
The hybrid solution I’ve been toying with is to generate a separate task for each recurrance, but also store the inital task information along with the IDs of all of the tasks that were generated. Then if someone changes one of the recurring tasks, I can prompt them:
This is a recurring task, how do you want to proceed?
() Change all recurrances of this task.
() Change all future recurrances of this task.
() Change only this task.
[] Also change tasks that have been modified individually.
() = radio button
[] = checkbox
Then I can loop through all of the recurring tasks and apply the changes to all of the tasks.
The problem this still doesn’t address is: How do I handle this in the heirarchy?
Let’s say I have a category ‘Home Computer’ and I want to create a recurring task ‘Backups’ to be done every Sunday for 1 year. Now I have 52 tasks under the Home Computer category. That makes the collective completion status of the Home Computer category a bit misleading. And I don’t think people want to see 52 of the same task at once under the parent task either. Only one of the tasks is really ‘due’ for this week.
Unfortunately, even if I add an exception so that only the tasks that are currently due (or overdue) count against the completion status of the parent task, then the parent task could inappropriately have a 100% completion status and be hidden from the main view. Also, I’d need some scheduled process to ‘activate’ the upcoming tasks.
It’s a bit of a mess… if you have any ideas on how to manage this, please pass them on to me.
UPDATE (2003-08-11): I’m going to try future dating the future tasks using Date Created and only show them after the current instance of the task is due. Look for this in 2.0.
This post is part of the project: Tasks Pro™. View the project timeline for more context on this post.
I haven’t had a new for recurring tasks yet as I’ve still just in my primal phase of using tasks, but I wanted to comment on recurring tasks.
If I understand your proposal then you’re going to create a seperate task for instance of of the recurrence? What about if I say “Give me a status report reminder even Friday until the end of time?” Mucho database spam.
What I’ve done in the past (for non-web-based applications) is to create a separate kind of virtual recurring task which exists more of as a policy (status task, every friday, end of time) rather than a specific task.
Making any sense here?
The problem is the heirarchy. I agree that it bloats the database, but without keeping a task for each occurance, calculating the completion of the parent tasks and allowing people to make changes to individual occurances of recurring tasks would be very difficult. This leads me to think that a record for each occurance is the right way to go.
Yeah, it’s a ton of work to calculate recurrences. Especially if you start to give options to OCCUR EVERY FRIDAY or EVERY OTHER WEEK or NEVER ON HOLIDAYS.
Still, you’re going to need to artificially limit recurrences via your App by not allow ongoing recurrences, right? There will be a limit to the # of recurrences that can be created.
Yes, I agree I’ll need to set some limit. There are probably a lot of things I need to account for that I haven’t fully thought through yet.
I think that percentages are usually not applicable for recurring tasks.
For instance, if you have 2 subtasks and one of them is daily, after 100 days, the percent done will always be 99%
For that same reason, I think that having
a new task each time is also a bad idea because the database will get large quickly. I think the best solution is to have a single task, that if marked daily, reappears each day, and people can use the ‘insert date/time’ button to update the task and then just delete/markcomplete as usual.
The the next day/week/etc.., the deleted task would “undelete” itself with comments intack.
The percentages can’t be marginalized in a heirarchical system because the recurring tasks can occur in a tree along with non-recurring tasks.
Personally, I’d want to be able to modify each occurance so that will definitely be a factor as I build it. 🙂
For anyone wanting a quick fix, here is what I have running in a daily cronjob.
It works for weekly,daily,and monthly if
the prefix of the task starts with
Sun-,DAILY-,3rd- respectively. Also note,
that using this, the only way to permanently remove the task is to change the title first.
update tasks.tasks set obsolete=0,status=0,parent=0 where substring_index(title,’-‘,1) = date_format(now(),’%D’) or substring_index(title,’-‘,1) = ‘DAILY’ or substring_index(title,’-‘,1) = date_format(now(),’%a’);