How can I filter dynamic displays groups with AND search terms like "A +B +C"?

[Patrick_Puddu]

CMS Version

Version 3.0.8 Docker

Issue

I uses dynamic display groups since a long time now. In v2.x I have search/filter terms like

id[1-9][0-9] # should be “id10” OR “id11” OR … “id99” (idXY are a substrings)
id60 Wien Hbf Kundenservice # should be “id60…” AND “Wien” AND “Hbf” AND “Kundenservice”
Reiseb\üro -Wien # should be “Reisebüro” AND NOT “Wien”

but non of them works anymore. Sadly a customer found out that it (obviously) breaks some serious stuff scheduled with display groups. Now it shows wrong content on some displays, which even means possible legal problems.

I noticed since v3.0.1 that the Name filter (I think it’s the same code) in layouts, playlists a.s.o. doesn’t really work anymore (or at least that I can’t figure out how) but that was just an inconvenience. But now that I know that it also breaks the display group filter, it is a big problem.

I tried many things but I can’t even find out how the easiest thing work: termA AND termB
On a Testserver (v3.1.1) I have e.g. three layouts:

“Default Layout”
“Default Testlayout”
“Test”

Now I want to filter/find just “Default Testlayout” and tried (every time with and without the regex checkbox):

def test
def, test
def,test
def|test
def AND test
def +test
+def +test
def & test
def &test
def && test
def; test
def;test
and probably many other strange things.

Nothing works. I get all results or nothing at all.

So please can anyone point me to a description or explain it to me how I can reproduce the search terms I posted!?

[natasha]

Thank you for posting.

I am querying with our dev team how to (if you can) return an exact match without regex as that does look like that is no longer the case. I will update here as soon as I know more.

In the meantime, do try the following regex (with the box ticked) to match any layout that has def and test, in that order in the name: [Dd]ef.*[Tt]est.*

For Display Groups, if you want id10 or id11 or id60 etc, you would need to put it like this:
^id[0-9][0-9]
Which means match from the start, id followed by two digits.

If you wanted to to exactly match id60 Wien Hbf Kundenservice, for example, you would need to put the following: ^id60 Wien Hbf Kundenservice$

You can find further examples here which you may find helpful.

In v3.1.0, we have added native support for OR or AND matching of Tag Criteria for Displays/Display Groups which will potentially avoid issues arising from where someone accidentally renames a Display etc as the Tags persist:

So please do take a look at that if you have yet to do so.

[dan]

@natasha

I am querying with our dev team how to (if you can) return an exact match without regex as that does look like that is no longer the case. I will update here as soon as I know more.

I just took a quick look for you, and I can’t see any recent changes in the way exact match functionality works. We haven’t supported exact match without a regex for a long time - not in v2.

I’ve created your 3 example layouts on a 3.1.1, I’ve added a tag so that you don’t see my other layouts, but i’ll filter on name:

Name match:

This isn’t precisely an “exact name match” though, because we always filter using a LIKE clause. So if I add some more Layouts I get those too:

To get a true “exact match” you need to add a start/end token to your filter:

^Default Testlayout$

If you want to have two exact matches, you can add a , to run two independent filters in an OR configuration.

The - syntax can be a little confusing when paired with ,

Here we see “Test” and “Default Layout” which match because of the OR NOT 2, and the others with 2 in them because they match the “Default Testlayout” clause.

---

Dynamic display groups are always filtered using a regex, but otherwise all of the same rules apply.

@Patrick_Puddu

id60 Wien Hbf Kundenservice # should be “id60…” AND “Wien” AND “Hbf” AND “Kundenservice”

This is a change since v3.0.0 where we no longer support multiple clauses denoted by a space, see this issue. Space delimiting made it impossible to do exact match on anything with a space in it, which is the main reason for its removal.

id60,Wien,Hbf,Kundenservice will do the same as what used to happen with spaces, although my reading of it would be OR’s and not AND’s as you’ve indicated.

Doing ANDs is actually quite hard - you can do it with RegEx but the order is important so you end up with a massive clause to represent any of those out of order. If you’re ANDing that many terms together, would it be better to use an exact match, or perhaps tags?

---

We parse , to split into separate OR clauses and we parse - to negate a clause. Otherwise we use LIKE/RLIKE matches depending on whether the regex has been ticked or not.

I hope that helps.

@natasha should we look at some more write up in the manual?

[Patrick_Puddu]

First, thanks for all the descriptions!

My bad that I don’t write explicitly that I’m not interested in exact matches.
I want: substingA AND (NOT) substringB AND … (as it works in v2 (without regex))

That the ‘-’ stands for NOT isn’t confusing, it’s only logical ;). But if you mean the general usage of OR NOT… yes that’s a bit special :).

Really no offence BUT it is very strange for a search engine to do exact matches including spaces without quoting or mask the space and that more than one search term gets combined with OR not AND!? Even the most well known search engine to human kind (google) uses AND as standard and you have to use ‘|’ (or OR) for OR and spaces have to be quoted. And that’s even more strange when there are no easy way to AND it. And really bad if this comes as an “update”.

Why: “Space delimiting made it impossible to do exact match on anything with a space in it.”?
I would say: “exact match” (search term including quotes) … problem solved!?
Normal behavior: substr match … substr AND match
OR: substr|match (or: substr OR match) … substr OR match
NOT: this -notThis … this AND NOT notThis

In this current state, for me (and all my colleges in the office), the search field is mostly broken. I’m maybe wrong, but I would bet, most of the users are at least confused.

Now I could explain why folders or tags are less then suboptimal replacements but I think that’s not the point of this post. As for now I think I have to change every dynamic group filter to a manually one and have to carefully update them every time a new display gets added :(.

It is what it is, so now… can I kindly ask if “you” can implement a method to get the possibility back to search for: substingA AND (NOT) substingB AND …

[dan]

Apologies for not following up on your reply, I did have it logged as a task and you weren’t forgotten!

We will make a small change in 3.2 which will add the “AND” logical operator to name filters/dynamic criteria. This will AND the terms (terms still separated by a comma). So that this isn’t a breaking change, the default will be OR as it is now.

This will look like it does for tags:

Filtering: add a logical operator to the name filter

We’re happy to consider further changes to the syntax for defining how searches are performed, which would be a breaking change and something we consider for v4.