Allow REGEX filtering to support AND/OR operations

[designermonkey]

As asked about on the forum:

@designermonkey:

I'm planning a project, and I'm thinking about what I can and can't do.

Taking into consideration the OR , operator and AND + operators for datasource filtering, can I use them in conjunction with regexp: filters?

For example

regexp:{$param1}, regexp:{$param2}, regexp:{$param3}

@brendo:

I don't think so, at least not in the Core fields. I'm not sure the origins of it, but it looks like the Core fields just checks the first $data passed to the buildDSRetrievalSQL function instead of all possible values.

These are other things that would trip it up:

{$param1}, regexp:{$param2} - This would start the OR logic, but the second value would be interpreted literally as regexp:{$param2}

regexp:{$param1}, {$param2} - This would ignore {$param2} as the logic checks the first item in the data array, which is regexp:{$param1} and assumes the rest is also regexp.

While it would complicate the logic a little to make it work, it should be possible from a developers perspective I would think. Can you file a bug?

[designermonkey]

After reading your answer, and thinking, the question arises that if we were to do this, how would we advise to terminate the regex statement?

Because normal characters can be used, a user would possibly expect to use , or + in their statement too. How do users get to use these characters normally? Are they escaped somehow??

[brendo]

You can urlencode them and they'll work. I've had to do it before with date filtering, aka. later than today + 1 week

It's an interesting point, I suppose at the moment if you use a , or + in a regexp it will probably break the filtering.

[designermonkey]

Yeah. The way regex was meant to work originally was to take the entire string after the regexp: string and check for that, but like you say, I'm not sure what would happen using + or, at present.

I asked the question merely to prompt debate on it, but it is very advanced filtering, which may just bring more confusion to the table, which we obviously want to avoid.

I have got around my issue by customising the DS slightly to check for the existence of the params and alter the filter based on that.

[brendo]

Going to close this, regexp: is a bit of an oddity and I agree with you, it's pretty advanced filtering :)

Perhaps this style of filtering can be revisited after potential datasource changes with #699