Setting a specific Perspective for All and None

This does not work. The list still has the Projects that are ON HOLD and that also have the Tag SOMEDAY.


JJW

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.


JJW

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:

🌅 someday

The Tag is on the PROJECT not on any action inside the Project.

I’m still digging.


JJW

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)

Same here.

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.


JJW

@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:

2 Likes

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.


JJW

1 Like

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.


JJW

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).

Thanks.


JJW

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.


JJW

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:

  1. Add your search text to a project
  2. Create a perspective for that search text. You’ll see the actions under the matching project show up.
  3. 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.

1 Like

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.

I’m sure that if they decide to change the current behaviour of the text search they’ll do it with careful consideration of the implications (like they did in the transition from OF2 to OF3, which was thoughtfully implemented). The response you got from the support team, which right after describing the intended design mentions the request already in their database for ‘specific support’ for text search in the parents, makes me think that they are on top of this.

Like I said above, if the explicit filter rule is implemented at the same time as ‘fixing the bug’, we will be able to update our perspectives to match our current workflows. This would actually be better since they would be properly supported in the application with the best performance. I can also understand that some users would prefer a text search that is performed only on the attributes of each item.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.