Smart Group reporting inaccuracy when using "like" for version numbers

[map]

Anybody have any idea why the smart group I have set up to find machines running Excel 2019 would be finding and including machines running versions not specified?
Specifically, a machine that has Microsoft Excel version 15.37.17081500 is showing up in this group. Screenshot shows all the criteria in place to pull the group together.

[TristanH · Accepted solution]

You should use brackets:
and ( or or or )

[TristanH · Accepted solution]

You should use brackets:
and ( or or or )

[Hugonaut · Accepted solution]

what @TrH said - that's why you're experiencing that issue, the and , combined with or,or,or requires brackets

[map]

I tried that and it comes back with zero results, which is also inaccurate. There are at least 6, but probably more, that should be in this group. With the current configuration, it's returning ~60, including the machine referenced for the example in the original post. I really appreciate the responses; it's just the parentheses don't make it report correctly, either!

[map]

Just to check that it wasn't a misuse of the parentheses, I tried adding parens to every "or" criteria line (open and close on the same line for each stipulation) which didn't work either, then went back to what I'd tried before (open parentheses in the beginning of the first version stipulation, closed for the last version stipulation) and it now returns a more accurate account of the situation. I don't know how or why, but this time it appears to have worked.
Many thanks to you, @TrH and @Hugonaut :)

[JustDeWon]

@map , you'd probably be better off with creating an Extension Attribute.

[mschroder]

jamf now allows to use regular expressions, that allows to reduce the number of criteria by a lot.

[coachdnadel]

@mschroder can you please give an example or provide a more detailed explanation?

[ChrisCox]

You can replace all of the the Application Version criteria using the like operator with a single Application Version criteria using a matches regex operator. In this case the regex would be ^16.(1[7-9]|2[0-4]).[0-9]*$.

If you're not too familiar with regex, I can break it down bit by bit.

^ designates the beginning of the line

16 is a literal match for the number 16

. is a literal match for a period; it's escaped since a period has a special use in regex

(1[7-9]|2[0-4]) is a capturing group enclosed in parentheses that matches on two possible alternatives separated by the |
First alternative:
1[7-9] is a literal match for a 1 followed by a number in the range designated within brackets (i.e. 17, 18, 19)
Second alternative:
2[0-4] is a literal match for a 2 followed by a number in the range designated within brackets (i.e. 20, 21, 22, 23, 24)

. again, is a literal match for a period

[0-9] is a literal match for a number in the range designated within the brackets (i.e. 0,1,2,3,4,5,6,7,8,9)

* is a quantifier allowing for any number of the previous match; in this case the [0-9] can be matched zero or unlimited times, so [0-9]* acts as sort of a wild card for any integer or nothing at all

$ designates the end of the line

[stevewood]

And to tag on to @ChrisCox excellent post on using regex, you should stay away from using 'like' in Smart Groups because it is a "fuzzy" search and can hammer your Tomcat nodes causing slow downs and possible lockups if you have not converted to InnoDB for your database tables. Smart Groups are recalculated every time a computer updates inventory, so if you have a large population of computers, you're bound to have a few doing inventory updates at any one time. That means a lot of recalculations, which means a lot of work for your database.