+1 Seems like a very useful feature.
In the process, should we also clean up the labels in the dialog box? The top two rows are straightforward, but what does the bottom (quoted below) even mean?

Set recurrence on
 [] the date that the todo is due. Show the todo:  [] always   []  days before the todo is due
 [] the date todo comes from tickler (no due date set)

I believe this (but didn't look into this) already is the case for todos that recur every 5 days for example. Or every two weeks. Or every 6 months. Tracks starts the clock after checking the first todo as finished

This will not be the case if you choose a specific day, like every monday of every week.

@Christian. I'll take text improvements. The bottom options is to select the due_date to repeat or the show_from date. In the first case, you can leave the show_from empty (show always) or set the show_from date x days before the due date

hmmm... Maybe your right, I hadn't thought about using a daily recurrence... When doing one of these longer term ones I end up clicking the Monthly or Weekly recurrence period which seems to get me into what I think I am doing with them. I suppose I should pick daily and make it every 180 days... The trouble with testing these recurring todos, I really need to be able to fool tracks into think the date is something that it not. I can make a two week recurring todo, check it off and see that makes the new todo, but if I want to see what happens after say 3 weeks, I kind have to wait 3 weeks to see :) I don't really want to change the time on the server as that could muck with other programs. Maybe it could do it in my virtual machine instance...

The pain point I have had with these recurring todos is that if I don't check off the current todo until after when it is suppose to recur it marks the recurring todo as complete. That is if I have a todo that repeats weekly on Monday's, but don't check it off until over a week after it was due, then I don't get a new todo for the next monday... Or at least that seems to be what happens.

Reinier, thanks for clarifying. How about this:

Use the computation to set the action's
[] 'Show from' date (do not set a due date)
[] Due date.  Show the action:
     [] always
     [] not until [ ] days before the due date

Not sure this is much of an improvement, but it seems clearer to me (possibly only because I wrote it). Other folks should weigh in.

@Tim, you can write (and look at) unit tests or functional tests for recurring todos. I think I have tests for these. And Every 180 Days should be equivalent of Every 6 Months.

@Christian: I like your improvement although we need to take it further. I can work from that... Could you create a separate ticket for this (for 2.2)?

Back to looking at this. I have continued to find erratic behavior with this feature. I am suspicious that my issues may stem from "completed" recurring todos or completed todos that were reactivating. It seems like when I have the same recurring todo description, I get issues.

So, I went in and cleaned out all my "completed" recurring todos as well as todos in the tickler that were related to the problem todos. I am now going to recreate the ones I need and watch them carefully. This way I can better monitor the behavior and perhaps see why it comes off the rails some times.

Looking at the add form, maybe "Starts on" should say "first action due on". Starts on confuses me (but I might be slow sometimes)

that is not the same. You can start a recurring todo on monday due every saturday. Starts_on=monday, but first occurence is for the first saturday after that monday...

the recurring todos's do nothing specific with the description, so that should not be of influence. Todo's are linked to RecurringTodo's (== recurrence pattern) using a foreign key. The key is not cleared for completed todos's when you mark a recurrence pattern as completed.

So issues could occur for old todo's that are reactivated (while the recurring todo pattern is completed) or perhaps restored databases where auto-keys are reset or something like that? Or of course plain bugs :-)

Thanks for the brief expanation of the linking method. Sounds much better than using the description.

Yes, you are correct about my starts on suggestion. Not an improvement, but I am still confused.

So I did some testing. Say I want to create a recurring todo to bill a client every 3 months, but not three months from today - I want it quarterly as they were already billed for the current period - Jan, Apr, Jul, and Oct.
All with monthly repeats on the 2nd day every 3 months with no due date:

1. if I creating it to start on 27-Nov-2012 = In tickler to show in 67 days or 02-Feb
2. if I creating it to start on 02-Jan-2013 = In tickler to show in 126 days or 02-Apr
3. if I creating it to start on 02-Dec-2012 = In tickler to show in 95 days or 02-Mar
4. if I creating it to start on 15-Dec-2012 = In tickler to show in 95 days or 02-Mar
5. if I creating it to start on 01-Jan-2013 = In tickler to show in 36 days or 02-Jan (Bingo!)

So the last set up works. I am just not sure how to explain it. If I wanted to make this example's first occurrence to be 01-Jan-2013, I feel like I would be stuck.
That's about all I should give to it now, but I will look after it as I have time.

I agree this is hard to get right in a GUI.

The code starts either from today or from the start_from date. (the latest of the two). Then it finds the first possibility that matches the pattern.
1) I think it goes back to 2-Nov-2012 and adds 3 months, resulting in 2-feb-2013
2) I think it decides that 2-Jan is not an option as its the same as the start date, so the next one is 3 months later, i.e. 2-apr. That's why 5) is ok, since the first next option is 2-jan. We could consider this as a bug, i.e. start_from should be a valid option too (for at least monthly patterns)
3) same as 2), it skips december and goes 3 months further
4) this one makes sence. 2-mar is the first matching the pattern

I think we should make 2-jan work so use-case 2) will result in the first todo being shown (or due) on 2-jan and not 2-apr

Yes, it is a tough GUI to communicate how to use tool, but it does basically work and I think most of the issues are small niche cases like this quarterly thing as well as providing some additional guidance as to what does what.
One thought I had was to give the user a confirmation box telling them what they had created. One if the issues I have run into is setting one up wrong and then having to correct it. You can update the recurring todo, but I don't think that updates any todos that were created with the recurring. So you have to edit it twice. So my thinking would be to call up a javascript popup window that would show you the actual recurring todo that you made. Something like, "Your new recurring action will be: 'todo description' starting on x date and then recurring every y for x times" If you clicked Ok button, the recurring todo would be created or if cancel, you would go back to the form to fix your issue...

I like that idea! Perhaps add an option to not show the dialog anymore for those who do not like confirmations. We have a textual representation of the recurrence pattern in the model that we use on the index page, so it is not very difficult. Could you drop this in a separate ticket?

Can we go back to the drawing board with this idea of a popup? If we need a popup, then we have more work to do to make the Tracks UI something that is more accessible. If the people working on the project can't figure out how a feature works, then it seems like that screams for a different approach to the problem.

My two cents. 


Thanks,
Matt

The GUI now is largly inspired by Outlook's dialog. I also heard from another devloper that a good gui for repeating todos is hard. We could do something with "basic" and "advanced" options to hide complexity.

Of course is a redesign an option, so if we have some ideas mocked up, we could discuss it of course.

Moved my discussion over to #1273 which seems like a more appropriate ticket. This one is about underlying functionality and #1273 is about UI.

#1273 is fixed. This ticket is in IHO only for the use case (2) of Tim

(In tracks-tickets:56b884055fcc2af8c07fe277e9fbd5c645e5ded7) fix #1270. if start-from fits the recurrence pattern, the first todo should use the start-from date

this is use-case 2 mentioned in the ticket.

Branch: master