I was wondering if it’s possible to cancel or drop a single task so that it can be removed as an actionable/outstanding item, but not deleted entirely?
Or is there another workflow that is meant to replace this sort of functionality?
2 Likes
This doesn’t currently exist – a task’s only two valid states are active and completed. I’m interested, though, in the specific use case backing this question. May I ask why you’re trying to drop an individual task? What would that accomplish for you?
1 Like
Hi @tekl, thank you for the prompt response. In some design projects I’ve been working on lately, some clients have deliberated on changes but then changed their mind, and I’ve found myself looking for the original task and its relevant notes/attachments.
At the moment, I have kept such tasks that may potentially return as ‘unfinished’, which can also get in the way of an at a glance view of what still remains to be done.
Or should I be approaching such things another way?
Have you considered putting these tasks in a context that is on hold? The default database includes such a context (called “Waiting”). Tasks in contexts on hold aren’t considered available, so you could place these tasks in the “Waiting” context and set your view filter to “Available” to keep them out of your day-to-day lists.
Would that work for you?
2 Likes
Hi tekl
I would like to second that idea.
A cancelled status would remove tasks from my gtd stream, but still keep them and all their details in the omnifocus database for retrieval and quotas later.
Thanks in advance
I’m sorry to bring this up again, but I’ve been so busy and have had to ignore my issues with this.
I’ve tried putting these tasks I wish to ‘cancel’ into a ‘waiting’ context, and then even had to follow this link on how to hide ‘on hold’ contexts from the forecast, but it doesn’t seem to work?
I’m a bit surprised no one has found a need to remove tasks without removing them completely from the database or simply marking them complete. It seems so useful for me to be able to remove these tasks from cluttering up my forecast but still be able to see them when focusing on a specific project to see if a task should be revisited or not? Simply marking them as ‘completed’ provides no context for differentiating them from normal completed tasks either.
As you note, the suggestion from @tekl does not work. It does not work specifically in those cases where a task is in a sequential workflow. The rest of the workflow gets put into a “waiting for” state.
I have the same need as well. I occasionally need to sideline a task that has not been completed and probably will not be completed, even as the rest of project will be done. I think the request to allow a task-level setting as “dropped” has been posted on occasion over time starting from the distance past.
To your original post about alternative workflows, I have discovered two “work-arounds”. One is to just mark the task completed. The other is to delete it. WRT tracking workflow historically in terms of such categories as tasks done, tasks sidelined, and tasks completed, both options fail. Another option that I had considered is to create a context “sidelined”, mark a task as completed, and move it to the sidelined context. This started to get a bit cumbersome and I have not really implemented it in practice.
I can suggest an option that may work. One is to create a sub-context to “Waiting On” called “Client”. Set up your project sheet with a task such as “decide next step on task XYZ”. Attach to this a sub-task “do task XYZ”. When the client tells you that you must do task XYZ, you check off “decide …” and have the task “do …” appear. Otherwise, when the client tells you they have decided to drop task XYZ, you check off “decide …” and delete the task “do …”. This still has the pitfall that sequential project workflows stall because they are pinned to this one task “decide …”
I think, when you have ongoing workflows that require options to sideline a task in an intelligent, intuitive way and still move forward on the remaining project, you will eventually have to develop the project layout in something other than OF. I doubt that a feature to “drop” a task (as an alternative to “complete” it) will get implemented in OF in any near term.
HTH
One remaining note …
In a strict sense of the process to set up parallel and sequential stages to complete a project, you should never have a step that pins your workflow and hides the ability to do other tasks even though they are possible to do. In this regard, one could ask whether you have defined your workflow properly to allow for tasks to be in a state of perhaps/perhaps not, with the outcome affecting only those next steps that depend on the decision and absolutely not anything else in the workflow.
Ultimately then, I return to my prior suggestion for the scenario that you seem to have. Create a task that requires “decide …” rather than one that demands “do …”. Make action on the “decide …” task control ONLY the immediate next sequential step (the “do …” step). Have absolutely nothing else in the project’s workflow that depends on the outcome of the "decide … " step. This may mean that you have to reshuffle the layout of your project template.
In addition, you may want to consider to separate the use of OF as an implementation of GTD from your need to track the post-status of tasks done, dropped, and pending on a project. Do this report about the historical progress and current status on the project in some other way than using OF.
1 Like
Some good points above about using different systems… This is why I almost never keep any real “notes” in OmniFocus – apps like Evernote are far better suited to that, and you can easily simply paste a link to an Evernote item right within a task field. In the end, if the task disappears, the notes are presumably still locatable in Evernote via some other method.
There are in fact even some Applescripts out there that can be easily used to tie to the two together in a more seamless manner if you want a directly linear relationship.
In my workflow, I generally do all of my note-taking, documentation, planning, spec’ing, etc., within Evernote. I use notebooks and tags to organize projects and clients, and then paste links into OmniFocus when there’s an actionable item attached to a note. While this may seem like double-entry in some cases, it’s definitely more robust as Evernote is designed to be a note-taking app, and is a much better place for storing drawings, screenshots, proposal documents, and other assets, so it only makes sense to me to keep the text notes right alongside them – in the same “folio” if you will.
The links from OmniFocus to Evernote even work within the iOS apps, so you can even easily pull up related notes from anywhere, and continue working on them and adding to them.
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.:)
