Wildcard tag search not saving correctly in Mac client

[xmasmoneky 72]

Note:  I have been working with Evernote support trying to track this bug down - opening it up to the community to see if anyone else can help me and/or verify this bug.

 

 

Background - I have my business ideas stored under tag "bizideas-mine" and interesting business ideas from others saved under tag "bizideas-others". I also have a tag "Dozen-blogged" to mark which ideas I have blogged about on my personal blog.

 

So here's the problem. I am trying to create a saved search to show me which business ideas (mine or from others) I haven't blogged about yet. Here is the grammar I use: -tag:Dozen-blogged tag:bizideas*

 

When I enter that search in the Mac search bar, it works like a charm. If I try to save the search, the Mac client keeps rewriting it as "-tag:Dozen-blogged tag:bizideas" (which ends up finding none of my notes). In the web client, the same saved search renders correctly. So the bug is not in how the saved search is stored - the bug is that the Mac client interprets the saved search incorrectly. I even tried uninstalling my Mac App Store version of Evernote and trying the latest direct client, but same problem.  I also tried using quotes - i.e. -tag:Dozen-blogged "tag:bizideas*" - but I get the same issue.

 

Anyone have any suggestions?

 

 

 

Step 1 - Direct Search Works

 

 

 

Step 2 - Saving the Search

 

 

 

Step 3 - Running the Saved Search Returns Nothing

 

 

 

[Adjusting 276]

Thanks for reporting this. This is indeed a bug.

I’ve reported it internally.

[sgray 0]

Any update here?

 

I'm having the same problem, although I think it can be narrowed down to only happening when a tag exists that's named with the text before the *. So the saved search for "tag:bizideas*" is interpreted incorrectly in the Mac client as "tag:bizideas" only if the tag "bizideas" exists. Otherwise, it's interpreted correctly (i.e., if you only had the tags "bizideas-mine" and "bizideas-others").

[Adjusting 276]

This bug was fixed way back in 6.0.6. Somehow it has been reintroduced since then. We’re looking into it.

Thanks for bringing this to our attention.