I really agree that we need one more state for actions like “Declined” or “Cancelled”.
Now I just have to mark them as “Done” and change their titles with prefix “[cancelled]”
1 Like
I also want to know the answer, because also i also ihve this question.
Yes, this is tracked in our development database. However, it will require a change in file format, so is quite unlikely to occur very soon.
1 Like
As a workaround is it not possible to add a ‘Tag’ to those items (f.e. ‘<>’), mark them ‘Completed’ and create a ‘Perspective’ for those tagged items - sorted by ‘Project’ or whatever?
I suppose what I’m doing now is putting them into a @dropped context and then marking them complete, which is not so ideal… It’s odd because why would a project itself have a status for Dropped but not a task?
This can be automated through the Applescript shown at this link.
I would propose this means, in the world of OmniFocus, you are only allowed to generate tasks when you are certain that you will complete them. Otherwise, you are to erase them. By comparison, you are allowed to have projects that are never fully actualized (completed) and you are allowed to drop them rather than erase them.
I would guess it is this way because adding a drop status on a task makes it more than selecting a binary status (active / done), and programming to select binary status settings are far easier to code than programming to select multiple choice settings.
I don’t agree with the logic either BTW.
–
JJW
I think it’s a bigger issue, too, where it comes to repeating things. I would love to drop/cancel an instance without losing the thread on future instances.
ScottyJ
Yes, quite true. I modified the Applescript so that it will also undo “dropped” tasks (remove any “dropped” markers) specifically because the drop makers were carried over when the project repeated itself.
–
JJW
1 Like
I realise this is an old thread, but I too need to be able to drop or cancel a task. My tasks are often set by others and then overseen by a third party. If a project is not as successful, timely etc as it could be, then I need to be able to explain exactly what happened, The easiest way is to show a cancelled task with an explanation in the notes as to why.
Then by printing the whole project in date order, it is obvious why things happened as they did.
I also want to know the answer, because also i also have this question.:)
This is exactly the workaround I currently use for this.
The “@dropped” context itself is set as “on hold” status. I wish I could use the “dropped” status, but this results in OF1 doesn’t show it in the list of contexts I can set an action to. If OF2 does the same (which I didn’t check yet), then it doesn’t seem to be a problem with DB format–but only with how existing status is interpreted (attn @lizard).
I do not use any special contexts for cancelled tasks.
Do not like the idea to change an original context with something artificial…
Currently, if I decide to cancel the task then I do this steps:
- mark the task as “Done”;
- date of completion is set to “Today” - since I cancelled this task TODAY;
- add a postfix like “[cancelled - %reason%]” (or simply “[leave it]”).
Examples:
“Repair the laptop” -> “Repair the laptop [cancelled - bought a new one]”
“Run 10 km” -> “Run 10 km [leave it]”
Basically I use OF in iPad.
And in iOS a task’s note is not visible in the tasks list - you have to open the task to see it.
That’s why I AM TRYING NOT USING NOTES - everything is specified in “[…]” and is displayed in tasks list.
Of course, I cannot see all these cancelled tasks in a perspective…
Actually, usually I do not need to reconsider these cancelled tasks.
But there is a workaround: if you always use postfix “[cancelled …]” then you can list all these cancelled tasks by simple search.
1 Like
Hello
+1 for this feature. I have a task in a sequential flow, and i need to cancel the task. But, i don’t want to lose the history of this task, or remove it from it’s current position. Just gray it out, and treat it as if it’s not there (in terms of project completion).
One reason is that i might want to activate it later.
thx
We’ve long planned to add both “On Hold” and “Dropped” states for individual tasks just like we have on projects, we just need to implement backwards- and forwards-compatible syncing first to let people transition from the less featureful data format to the newer data format.
Transitioning to this new sync format is our next major milestone (on both Mac and iOS), and will make it possible for us to move forward with planned changes like this one. I’m looking forward to it!
5 Likes
The set of new statuses to be added: is it finalized now, or still open for input from users?
Well, these states aren’t really new: both already exist on projects, so their behavior is well-defined, have translations in all our languages, have icons and documentation that explain what they mean, etc.
That said, if you have more states you’d like to suggest please do let us know!
Hi kcase, do you have an expected date for this? OF moved to a new sync encrypted format last year so it should be possible now to have dropped tasks.
I guess is it expected behaviour that it is not possible to set dropped state context to a task. I understand that as the context is dropped it does not appear in the list, but at least OF should allow to set it (by writing the dropped context name)
The file format is no longer blocking us, so this year we’ve been making fundamental improvements to our file format, starting with faster attachment syncing (now shipped), support for multiple tags, and more flexible repeats and notifications. Dropping tasks is a pet wish of mine, but it hasn’t been requested so frequently yet as to make this year’s official roadmap. (But we might manage to fit it into this year’s database changes anyway.)
5 Likes
💜 great response!
1 Like
