I have Projects that are ON HOLD. I have marked some of those Projects with a specific Tag --> SOMEDAY.
I want to set a Perspective that will give me ONLY the Projects that are ON HOLD and that also DO NOT have the Tag --> SOMEDAY.
Clearly I am not understanding how to set the All and None criteria. I cannot find a proper way to make this search work. Any combination I make still returns the ON HOLD Projects that have the SOMEDAY Tag.
ps … I also do not want to see the Projects that are COMPLETED. Using the selection for Projects that are NOT ACTIVE (rather than ON HOLD) returns the COMPLETED Projects too.
I’d appreciate any insights.
@DrJJWMac, is this what you are looking for ? I think it should work.
This does not work. The list still has the Projects that are ON HOLD and that also have the Tag SOMEDAY.
I cannot reproduce it. In my case, it excludes those ON HOLD Projects which have a Someday Tag.
OK. Perhaps it is because my SOMEDAY tag is a sub-set tag. Let me look further.
Do you mean that it is nested in another tag ?
Yes. But nesting seems not to be the problem. I also use an icon before the tag name. It is this:
The Tag is on the PROJECT not on any action inside the Project.
I’m still digging.
Yes, that what I interpreted.
I pasted your emoji into a tag and still have correct results.
My OmniFocus version is: 3.6.4 (v140.16.3)
I’ve tried numerous iterations of putting the tag in a different group or by itself, removing the emoji, putting the tag on an action rather than on the project, and even putting the tag on an action in a different project. What I have resolved is that using the negation will remove a TASK from the view, it does not however remove a PROJECT or an ACTION GROUP from the view.
Whatever the issue is, it appears to be local to my system. I am still on Mojave when that might matter. I am also doing a Project view rather than a Task view.
@DrJJWMac Yes, the perspective rules filter individual actions, not entire projects. For filtering purposes, a project is just the top-level action group.
You can specify criteria about the project which an action is part of using the ‘Has a project which…’ set of rules. The tags attached to a project are not part of this set of rules, so there is no possible combination of rules which will return the entire contents of projects based on referring explicitly to the tags of the projects.
You can however do it in an indirect way by using the text-search rule. This works because all the parent actions including their tags and notes are part of the search scope (this is very convenient and I’ve written before on how I use that with markers in project names).
For this approach to work cleanly, the tag name (or marker name) should be a unique string in your database; if you’ve typed the same string in other actions they will pollute your results. A good way to ensure this is to include an emoji or special symbol in the tag name, like you did.
So I think this returns what you’re after:
Thank you. This solves my problem.
ps … Oddly though, the inverse search does find Projects with the tag even when the Tasks inside those Projects do not have the Tag.
The problem seems to be associated with using None as the prefix to the search, not with searching on matching tags.
That search will return the project item itself (it’s treated like the top-level action), but not all the actions inside the project.
To summarize: Using two lines, I can directly find all Projects that are tagged with SOMEDAY and that are ON HOLD. I cannot exactly invert the one line in the search criteria to find all Projects that are NOT tagged with SOMEDAY and that are ON HOLD.
The scope of All is not the same as the scope of None. The two criteria are not the exact inverses of each other.
The approach is inconsistent. In logic, an inconsistent approach is a flaw. Regardless that the presence of this flaw in the search logic allows for convenience in certain searches, it remains a flaw.
No, I think it’s working correctly and logically consistently as designed.
Remember what I said earlier: it’s the actions which are filtered, not your projects as a whole. If you switch your perspective to the setting ‘Group and sort: Individual Actions’, you’ll see that the project item which has the ‘Someday’ tag is not being returned.
Now consider the effect of the ‘Group and sort: Entire Projects’ setting. This adds all the parent items (up to the project level) of the actions which were filtered by the rules, to show everything in context. Your perspective rules are returning actions inside the project tagged ‘Someday’, since those are not tagged ‘Someday’ individually. So the ultimate parent — the project item — is being displayed as well.
Alright. So this …
… is not the exact inverse of this …
I am tagging ONLY the Project. I am not tagging at the task level. In the second case, I get the Projects that have the tag SOMEDAY. This implies, the scope ALL finds the Projects tagged with SOMEDAY because the tasks inside of it IMPLICITLY have the tag SOMEDAY. In the first case, I cannot exclude the Projects that have the tag SOMEDAY. This implies, the scope of NONE does not exclude the Projects tagged with SOMEDAY because the tasks inside of it do not EXPLICITLY have the tag SOMEDAY.
The scope of NONE is not the exact inverse from ALL. The scope of ALL is broader (implicit) compared to the scope of NONE (explicit).
I cannot see any other logically consistent framework to make this make sense.
I see the logic once the terms implicit and explicit are added. I still consider this a design flaw. Perhaps it is a design flaw however only in the terms being used. I would have to think whether a better set of counter terms would be appropriate: All / (Mostly) None or (Fully) All / (Limited) None or All (Implicit) / None (Explicit).
I’m sorry, I don’t follow your reasoning at all :)
Step 1, the rules are applied to all the items (including project items at the top of a hierarchy of actions). ‘All’, ‘Any’, ‘None’ are just user-friendly ways of representing AND, OR, NOT clauses. There’s nothing implicit going on there.
Step 2, presentation options are applied: sorting and grouping of the results. With the ‘Entire Projects’ option, action items which are hierarchically between the results of Step 1 and the project-level items are added, and it is the “entire projects” which are grouped and sorted.
Did you try putting your two perspectives into ‘Individual Actions’ mode? This should make it clearer what the rules are doing.
Hope this helps!
Here is an alternate explanation.
- The ALL rule finds tasks that are tagged, even when they are IMPLICITLY tagged.
- The NONE rule finds tasks that are NOT tagged, but only when they are EXPLICITLY NOT tagged.
Also substitute the phrases “tagged only by inheritance” for “implicitly tagged” and “tagged directly” for “explicitly tagged” to see if that helps.
Ultimately, the difference is not between a search on tasks versus projects. The difference is the full scope of All versus None.
Are you putting the search value in a tag on the project, or a project note?
(edit: I just tried this with tags, and it has the same problem. Remove the tag from the project, and the actions still appear in the perspective until you restart)
I’ve tried this with project notes, and am under the impression that OmniGroup considers this a bug, or at least did as of January 22, 2019. I say this because I reported buggy behavior around the search, at least some of which still applies today:
- Add your search text to a project
- Create a perspective for that search text. You’ll see the actions under the matching project show up.
- Now remove the search text from the project note. The actions still show up in the perspective. You have to restart OmniFocus to get the perspective to update.
Basically if the perspective exists prior to changing the project note, you have to restart OmniFocus to refresh the perspective.
Here’s the response I received from support about this:
What’s interesting is part of the behavior you are used to and expect is actually a bug. You are filtering for items that match the term ⭐️. By design only items that themselves contain that emoji should be included in the filter. It is not expected that the items within a project would appear unless they also contain that emoji. For instance, if you were to try the same thing but use tags and the “Tagged with any of” filter rule, this is the behavior you would get.
That said, we do have a request for specific support to filter for tasks whose project or group contains the search term/tag/etc. I’ll get you added to that, and file another bug about the inconsistent behavior with the “Matches search term” rule.
I like to put the value (usually a symbol) in the project name, but it works the same if the value is in the notes of the project or in the name of a tag on the project (and the same applies to parent action groups).
My workflow using markers in item names: Two OF3 Perspectives puzzlers
People using tags: Best way to prioritize Projects and Actions in OmniFocus in 2020?
People using text notes: Need help w/ a custom perspective
Yes, I’ve noticed that the refresh of the perspectives which use the text-search rule isn’t always immediate, especially when removing the text string like you described. I’ve never restarted OF for this though. I’m not sure exactly which conditions trigger a refresh, but I’ve been able to obtain it by closing the OF window/tab and opening the perspective in a new one.
Thanks for sharing the response from the support team. If they implemented both changes simultaneously, there would be no loss of functionality (even originally unintended).
To be able to reproduce the behaviour that I and others currently rely on, the new rule would need to be “Has a parent which matches search terms:”, where ‘a parent’ could be the project or a parent action group (they could even extend this to folder names for additional superpowers!), and matching in tag names or notes text continues to apply.
Cool, thanks for those links. The search approach also delivers some functionality that I’ve wanted for a while, showing the available action hierarchy.
It’s too bad that perspectives using this approach are slow to update – leading me to believe it just didn’t work, so I abandoned it. And it’s really too bad that if Omni ever gets around to “fixing” this, they’ll probably break this for us because they consider the current behavior to be a bug in the first place.