Auto-unflag checked items

[quote=“zdlo, post:17, topic:20498, full:true”]
I think if such implementation is necessary, then the default behaviour should be to unflag everything automatically once completed, since most people seem to not have any need to keep the flags after completion.[/quote]
Disagree with this one completely – in my case it’s the exception, not the rule. Most of my repeating tasks that are flagged should stay flagged so that they come up in my daily “hotlist” each day. An option to UNflag them would be useless to me, although it would be nice to be able to do override this on a per-task basis.

Essentially, I use flags on tasks in one of two scenarios… My repeating tasks for my daily and weekly routine, which are always flagged and stay flagged no matter what (things like “Take Vitamins” and “Reminder daughter to do homework”). This is because I work from a “Hotlist” that only includes flagged and due items and use those flags to determine what appears on my Hotlist.

The other use case is those one-offs that I pull from another list. I might have a routine household chore that doesn’t normally merit inclusion on my Hotlist, but this time around does as it’s something I want to get to. I’ll flag that to bring it up on my “Things I should do today” (as opposed to “Things I could do today”), and when I complete it, it recurs in another few days. This isn’t really the end of the world if it’s still flagged when I complete it, as I can easily remove the flag when it comes back up, but it would be nice to have it automatically removed upon completion. I’d probably use flags more if this options were available. As it stands right now, it’s not that much trouble to remove the flag before marking it complete, especially now that the iOS app provides a swipe-to-unflag option.

[quote=“deturbulence, post:20, topic:20498, full:true”]
Actually, I would say I appreciate completed items remaining flagged. It shows me the difference in my historical activity between work I did because it was flagged and work I did because I just did it.[/quote]
I’m similarly OCD in the opposite direction of @zdlo :)

I almost never look at my complete tasks as a list. I’m more likely to search for something if I want to check when it was completed (which I do on a semi-regular basis), but beyond that, done is gone for me. Look to the future not the past! ;P

That said, however, I prefer that everything that does get completed remains in the exact same context that it was in when it was completed. As much as I don’t look at completed tasks, I’m a digital packrat when it comes to keeping information around, and I like the fact that I can trust OmniFocus to keep track of all of this stuff for me for those times when I do need to look back and check on something.

That said, of course, I’m not disparaging @zdlo’s approach either. The beauty of OmniFocus is that it is in so many ways a more open system that doesn’t force you to approach things in any singular way. We all take different approaches to what flags, contexts, and even projects mean in each of our worlds.

@jdh oh absolutely no intent to disparage @zdlo’s approach either! Yes, it’s interesting to hear about other workflows and matters of importance, this one just doesn’t happen to resonate with me, but that’s not because its intent is wrong, it’s just different from mine.

The importance of a personal approach and individual workflow that works for the self can’t be understated :)

ScottyJ

1 Like

So I’ve hacked together an Applescript that when run will go through the current OmniFocus document and UNflag all completed tasks that are flagged. Obviously it’s not much different in concept from doing this manually, but has the advantage that you can run it on a semi-regular schedule (e.g. using a daily task scheduler app) to take care of cleaning up your completed tasks that still have flags.

UPDATE: I’ve played with this a bit more and come up with a much simpler and more efficient way to handle this. As I said, I’m no Applescripting expert, particularly when it comes to OmniFocus, but this is considerably simpler and more straightforward than what I cooked up before. The inspiration came from @curt’s script to clean up notes that was posted here.

tell application "OmniFocus" tell default document set flagged of (every flattened task whose completed is true and flagged is true) to end tell end tell


Old kludgy and ugly version down here just for reference

tell application "OmniFocus"
      tell default document
            set myWindow to make new document window
            tell myWindow
                  set focus to {}
                  set selected sidebar tab to contexts tab
                  set selected trees of sidebar to sidebar
                  tell content
                        set selected grouping identifier to "none"
                        set selected task state filter identifier to "complete"
                        set selected task flagged filter identifier to "flagged"
                        set theItems to value of (every tree where class of its value is not item and class of its value is not folder)
                        repeat with eachItem in theItems
                              if completed of eachItem is true then
                                    set flagged of eachItem to false
                              end if
                        end repeat
                  end tell
                  close
            end tell
      end tell
end tell

I’m far from an OmniFocus scripting expert, so this may not be as elegant as it could be, but it works. If anybody has any suggestions or corrections, feel free to pick it apart and improve as necessary :)

1 Like

Thank you for the Applescript! Even though I don’t find regularly running such script more efficient than an implementation or manually keeping things organised at all times in a relatively less dense daily schedule, I certainly appreciate your effort, and I think it might help in certain circumstances.

As I read all other use cases, I tried hard to bend the way I use OF to fit with any other use in order to stop needing something that isn’t there, but it’s clear that flagging can be utilised to serve many different needs, and the way I would personally need it to be the most is definitely a super-state. I also think everyone agrees that repeating tasks might sometimes need the flag to behave differently.

That said, I would like to ask everyone again their opinions on the issue of how it will affect their view on flags when multiple-contexts become a reality.

For those who use flags merely as an additional context, is it still going to be needed for a flag to not be a super-state, once they are able to assign more than one context to each item? What if there were also smart lists in which you could have multiple contexts listed?

[quote=“zdlo, post:25, topic:20498, full:true”]
Thank you for the Applescript! Even though I don’t find regularly running such script more efficient than an implementation or manually keeping things organised at all times in a relatively less dense daily schedule, I certainly appreciate your effort, and I think it might help in certain circumstances.[/quote]
You’re welcome. Obviously it’s not an ideal solution, but it’s nice that so many edge cases that OmniFocus doesn’t directly address can be solved through Applescript, and it’s definitely a “now” solution since I don’t imagine implementing auto-unflagging will be high on Omni’s list.

I think there’s a serious “meta” discussion going on here with words like “super-states” and so forth – a term I’m still not entirely clear on your meaning for.

In my case, I suppose I use flags in a manner similar to what you’re describing, as they identify higher priority or “actionable” items. My entire core working list relies on flags and defer dates to put things there, and using multiple contexts wouldn’t change that behaviour for me unless it became the only option (e.g. flags were deprecated entirely). The only real difference is that I don’t look at my completed tasks often enough to care whether they’re flagged or not, and when I see one that’s flagged, I pretty much just ignore that fact. When looking at my completed tasks, I’m more concerned with completion date, project, and – maybe – context.

For a flag to be a super-state, it means its existence is always relevant and temporary. It can be used for any item, even for completed items, for whatever reason the user might have.

The opposite of this super-state is a flag being merely an additional context.

For instance, once multiple-context feature gets implemented (it’s already in the works), one will be able to use an additional context called “flag” or “hotlist” or whatever, and use a perspective showing all the items with that extra context and the due items together. If Omni also implements smart lists, users will also be able to use perspectives showing whatever contexts they want.

So, for someone who is using flags not as a super-state but as something they want the item to keep in order to remind them something about the item, this new feature will already make it possible to have the same function by use of extra contexts. One could then simply assign an additional context called “flag” or maybe something even more suiting their use, and achieve the same result. And then, even those users who are at the moment using flags differently, can start utilising the flag as a temporary super-state.

In case what I mean is still not clear, let me give an example:

User A, uses flags to indicate a needed property about any item, even for the completed items.
User B, uses flags to indicate a needed property about active items, but is not worried if completed items keep their flags.
User C, uses flags to indicate a needed property about any item, but for some items, a flag should only stay as long as the item is active.

(I’m a C user.)

Once Omni implements multiple-contexts, A users will be able to start using an extra context for the same purpose as what they are using flags for now. So, they won’t need flags to behave the way they do now. And if they do so, and flag get changed to behave as a super-state, then:

User A will still be able to have an indicator for any item that will be intact regardless of the completion state, plus they will now have an extra state, a super-state called “flag” to use for any action temporarily.
User B will still be able to have an indicator for the chosen status of active items, which can be automatically removed afterwards, so they will also be able to assign a flag to completed items for temporary use, such as moving them.
User C will be able to have an indicator for the chosen status of any item, and the completed ones can get their flags removed automatically, while completed items can also be flagged for temporary uses, such as moving them.

In such future scenario, user A wouldn’t need flags to behave the way they do, they can simply use an additional context instead for the same function, therefore the behaviour of flags can be changed to become a temporary super-state.

Automatic unflagging of completed items wouldn’t affect flags that are assigned after an item is completed, and there can also be a switch to alter the flag behaviour for individual repeating tasks, in the inspector panel.

My understanding is, the next reality will be an addition of tags, not an expansion to multiple contexts. Think Finder-style demarcations rather than being able to select more than one of your existing contexts.

In this situation, I would still want flags as a separate entity. Tags will help me search or filter on actions that should meet certain terms. Flags help me define what tasks within the return results are or are not in my “active” work bin.

Inverting the statements, I can say that I will not be happy to have flags folded in to the new paradigm of multiple contexts or tags.


JJW

1 Like

For your use of flags, could you elaborate on how it differs from simply adding a tag named “flagged”?

  • You will still be able to add it on top of all the other tags,
  • You will still be able to list them with or without due items,
  • You will still have the indicator of the tag on the item,
  • You will still keep having them after completion.

In Practice: A flag state standing by itself is an on/off toggle. Efficient. Period.

Conceptually: A flag is not just another tag. The former is a state that says “hey look at me (or don’t)”. The latter is a category of “hey, this is where I fit in your mind-map”.

Let’s keep the two clean. Add tags as tags, but keep flags as flags.


JJW

That’s why I think it should be a temporary state. The way you use flags doesn’t seem to be an on/off kind of use.

I use flags as toggles to tell me whether an action requires attention or not. The flag can be temporary in that it is on only for a short time. It can be permanent in that it is on a deferred repeating group so that it “pops up” when the defer date is reached.

After the task is complete, I don’t care that a task is flagged or not. Once a task is complete, temporary or permanent has no meaning to me.

I insist, the state of completion and the state of flag to be completely independent of one another. You seem to want to make them co-dependent. In particular, you seem to want that COMPLETE = NOT FLAGGED always. I insist that this demand is unreasonable. Even if only defined by a preference setting, then then default should still be for completion state and flagged state to be independent of one another.

The slippery slope when multiple contexts aka tags are setup is that thereafter, someone will insist that OF must act to have COMPLETED = RED BALL TAG always.


JJW

1 Like

It occurs to me that all of these edge cases would be easily solvable via Applescript if OmniFocus had added support for posted events, but sadly despite some discussions around it back in 2008 in the old forums, it doesn’t appear to have ever actually happened (at least I can’t find anything in the OmniFocus Applescript Dictionary indicating it’s there).

However, maybe that’s the feature we should really be requesting. If an event could fire off every time a task is completed, that would open up OmniFocus to all sorts of additional plug-ins and extensions, one of which could be to also UNflag the task (and another which could be to add a RED BALL tag :) ). I’d much rather see that then adding more preferences to account for edge cases such as @zdlo’s (no offence, but it is an edge case in the sense that in seven years of using OmniFocus, I don’t recall ever seeing any other suggestions for it :) ).

On the contrary, I think they should be independent. One might also need a completed item to have a flag (auto-completion of completed tasks shouldn’t prevent the user from being able to flag completed items). However, some of the flags we assign are only valid as long as the item is not completed.

I see your use case, but still, if you were using a tag instead, it would behave exactly the same; the item would disappear from your active items list once you completed it, and if it was repeated, it would repeat with the flag tag intact.

I would already vote for that, I guess, considering it wouldn’t cause performance issues or other problems, to have the ability to tailor OF to suit our individual needs with scripts.

However, about this case, whether it is an edge case or not, it obviously is not yet optimised to its ultimate elegance. I would expect it to have a different function than simply being another tag. Also, repeating tasks having or not having their flags intact, has been discussed many times before by many users. Sometimes we want them to repeat with their flags intact, sometimes we don’t.

Do you think an Applescript can differentiate between a completed task that was flagged at the time it was completed, and a task that was flagged after it was completed?

My counter would be that, those flags that have no meaning unless the item is not completed have no meaning even when the item is completed. Or, better said (as others here have stated) … out of sight, out of mind. Once the task is done, why continue to care whether its state is flagged or not? Why even bother? Do you go back and diligently count the number of completed tasks that have flags versus those that don’t? Do you make some post-mortem, weekly report based on this information? Does it affect or change how you move forward for the next period in your GTD world? Other than some vague “it is annoying” factor, I still do not have a good objective case on your part to address this critical question. What problem does your proposal solve that is objective not subjective?

It might behave the same. I sincerely and seriously doubt that it would be as easy to turn on and off as the current implementation.


JJW

1 Like

Yes. That would be the real kicker. Fire off an event when a task is marked as complete. It might have to be task specific though. I can think of cases where I would want it to happen and cases where I would not want it to happen, all within the same Project let alone within all of my OF world view.

As a kludge, you could modify the “Mark as Dropped” script I posted here to handle this. It would only work on the desktop though.


JJW

1 Like

I would appreciate an option that when the defer date arrives an item would automatically become flagged, much like how Things automatically moves an item to the Today view and marks it as yellow when the scheduled date (the defer date for OF) arrives. Presently I have to manually flag items every morning when the defer dates arrives. Occasionally I miss one and therefore it doesn’t show up on my Today perspective, which requires an item to be flagged.

[quote=“FW2, post:38, topic:20498, full:true”]
I would appreciate an option that when the defer date arrives an item would automatically become flagged…[/quote]

Actually, if you’re manually flagging when the defer date arrives, there’s probably something that could be better optimized in your Today perspective.

Deferred items should normally be excluded from a perspective until the defer time has passed, regardless of whether they’re flagged or not. Assuming of course you’re filtering for available items, as opposed to remaining items in that perspective.

My entire workflow revolves around the use of flags and defer dates, and the only time I ever worry about flagging something manually is during my weekly review, usually when I’m also assigning the defer date. My tasks remain invisible in my “Hotlist” until such time as that defer date (in fact, the defer time) has passed. If I have a really busy day, I sometimes even defer things to a specific time of day, and I very frequently defer regular evening household tasks for after I finish work so that they don’t clutter up my list before I can do anything about them.

Further, in my case, I don’t match flags to defer dates exclusively either. I have a number of secondary contexts that rely on defer dates to control how often things repeat (e.g. household chores) that I don’t want in my Hotlist, as I only work on them when I’m in that particular context.

I can see reasons why you may want to include ALL flagged tasks in a perspective, regardless of their availability, and since you haven’t really explained your workflow I’m not sure if that’s the case. That said, however, automatically flagged tasks when the Defer Date passes would actually take away an important semantic meaning of the flag (or lack of a flag) for many people.

I think there’s an important reason why OmniFocus treats all of these states as separate and distinct – it provides the product with the flexibility to be a toolbox that can be configured in a myriad of different ways to suite different workflows. OmniFocus is more of a productivity environment in that sense, rather than a productivity app. Apps like Things define your workflow, whereas OmniFocus merely enables it.

1 Like

I can’t see it creating any serious issues, although you’d obviously be restricted to enabling it on the desktop, which might be the weakest point in the link for many users. Not everybody uses OmniFocus for Mac, even primarily, and it might be unclear how events would be handled on the basis of the results of a sync, although I’m sure it could be dealt with.

It’s interesting to see the different viewpoints on things like this. I consider the fact that OmniFocus maintains semantic separation between a lot of properties and doesn’t make assumptions to be its greatest strength, and to me that’s a different form of elegance. While you still have to tailor your workflow to fit into it in some ways, I actually find it a lot less restrictive than most other systems I’ve used.

If it’s based on an event, it should absolutely be possible, since the idea would be to trigger the script at the moment of completion, at which point it would remove the flag. It wouldn’t be triggered otherwise. Similarly, if an event system were put into place, scripts could be triggered for any other set of task changes – including the addition and removal of a flag, and possibly even the passing of a defer date (as @FW2 requested).

Again, the only trick would be how to handle such events for sync operations, since the iOS versions of OmniFocus would not have these capabilities directly. I’d guess that the events would have to fire off based on state changes immediately after a sync occurred (e.g., if a task status changes from incomplete to complete during a sync, treat it as if the user locally clicked the “completed” button on the Mac side). I’m not a developer, so I have no idea what would be involved in doing this, however.