add a 'followup' button next to 'delete' and 'edit'
how about adding a 'followup' button next to 'delete' and 'edit' next to each action ?
It would mark the action as done, but prompt for the next action in the same project and propose the same context by default. E.g. I would mark 'call X about Y' done and immediately add 'wait for answer fro X about Y' as next action.
It would mark the action as done, but prompt for the next action in the same project and propose the same context by default. E.g. I would mark 'call X about Y' done and immediately add 'wait for answer fro X about Y' as next action.
Leave a comment
on 2009-12-22 18:03 *
By lrbalt
Status changed from Invalid to New
Status changed from Invalid to New
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
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.
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...
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
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.
#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