Nice idea.

As asked for on the mailing list. I vote a +1 for this one

Considering for 1.8

Updating tickets (#743, #752, #768, #781, #535, #47, #295, #298, #805, #806, #324, #584, #97, #592, #344, #603, #114, #629, #636, #645, #393, #405, #433, #434, #202, #462, #220, #233, #310, #95, #635, #397, #94)

This is already taken care of by the "Go to project page on todo complete" preference

I think the ticket is asking for some jquery magic, i.e. close the todo as completed and fill in the new todo form with the data from the completed ticket. This way you could quickly create a follow-up on the todo that was complete

Duplicated association with ticket #143 was added

I was thinking of this and my suggestion is this instead of creating a new todo:

In the edit menu add a 'follow-up' action which does:

1) look up the user-defined @followup context in the preferences (in my case 'waitingfor')
2) look up the user-defined @followup initial delay (could be 7 days)
3) change the context of the todo
4) change the show-from of the todo
5) save the todo
6) refresh the view

A good icon would be one of the 'share' from Fugue: http://www.freeiconsweb.com/search-icons.asp?find=share

This is easier to implement than some jquery magic.

I missed the discussion here, sorry for the late reply.

I do not agree with the suggestion. Tracks handles next-actions, so "ask XYZ to do stuff" is an action whcih you'll complete first and then you add "check if XYZ did stuff" in @waiting-for. So the initial requested behavior is correct IMHO, but just changing context and show-from is not.

Other example "write report for audit" is probably a project with the a next-action being "write first draft" followed by "gather comments on first draft". These are different actions, not the same action. The behavior above is more like handling a project without defining its next-action...

The problem is that many actions often go through local loops like:

#1 wait for person X to write report for audit
#2 review report for audit and leave comments
#3 wait for person X to address comments
#4 review report for audit and leave comments
#5 wait for person X to address comments
#6 review report for audit and leave comments
....

This is most easily implemented by just

• review report for audit and wait for person for comments

And then move it to the @waitinfor or to a different context.

I agree that it's better to create a new action instead of spinning on the current action, however, it makes it easier to handle dependencies.

Migrated to GitHub issue #233