Filter with enum text contains fails

Problems and solutions
1

Another thing we found out in the change of the behaviour with enums.

Preside 10.22.2: The following filter works fine:

image

Means: find me all attendees for the tomorrow event, booked for the online course (eventtype contains “o” for online).
The eventtype is an enum with three possible values: o, p, op (online, presence, hybrid).

the result right now is 161.

The same filter without any change doesn’t work in 10.23.17. Here this query returns ALL records for this object.
And by “ALL” I mean really all 15.000 records of the object!! Not all for the tomorrow event (also presence and online), really all records of this object!
It seems, that the query is breaking/not working and returning just all records.

In our case this led to the effect, that the email center sent out 15.000 emails reminding the attendees for all the events they registered - in the past and in the future.
The customer had to report an incident regarding a GDPR violation, and I had to answer a many questions.

In 10.23. the filter needs to be like this:

image

I now have to explicity have to choose the enum values. Which is fine.
I also understand, that the the mix of values doesn’t work (see [PRESIDECMS-2484] - JIRA).

But what I don’t understand: When enum filter only works with enum values. Why am I still offered the “text contains” option.

image

And if it works with “text contains” without mixing it with the enum values: Why do I get all records returned as described above?
I think this is a bug and there’s something wrong with the generated query, but I’m not able to debug it.

2

I also understand, that the the mix of values doesn’t work (see [PRESIDECMS-2484] - JIRA ).

From what I understand, ^^ this issue should have defended against the problem you are seeing. But it isn’t?

Is the Veranstaltungstyp [ enthalt ] [ "o" ] expression still available in 10.23? or has it been removed/changed to the second screenshot? In 10.22, are you able to inspect the DOM and paste the json value in the corresponding hidden textarea? This will help us reproduce this better (defo sounds like a bug).

3

I read the [PRESIDECMS-2484] - JIRA ticket as: “You can’t use “text contains” and “enum values” both in one filter, but one of them is fine”

The expression Veranstaltungstyp [ enthalt ] [ "o" ] is still available in 10.23 and was replaced in the second screenshot with the “enum values” filter.

This is the json value in the hidden field:

[
  {
    "expression": "presideobject_manytoonefilter_veranstaltung_user.veranstaltungid",
    "fields": { "value": "4AB78BFA-35CC-40BA-A77B8E6642F2D29B" }
  },
  "and",
  {
    "expression": "presideobject_stringmatches_veranstaltung_user.va_type",
    "fields": { "value": "O", "_stringOperator": "contains" }
  }
]

The code is identically in 10.22 and 10.23

4

Its the opposite I believe. That ticket was there to fix issues where existing data and rules would break with the change in the enum rules behaviour.

What is the enum value that should be matched by va_type contains “O” - does the raw value not contain O and we are expecting it to match on translated value?

Or I guess, what are the values of all the enums here? Trying to understand why it is matching all with va_type containing “O”…

5

This is the enum:

settings.enum.vaTyp                 = [ "p","o","op" ];

and this the i18n:

p.label=Pr\u00e4senzveranstaltung
o.label=Online-Veranstaltung
op.label=Hybrid-Veranstaltung

So at least the Online entry should be found, the Hybrid not.

I hope you’re going for values, not the label. If you’re going for labels this filter would depend on the language the user uses in the admin. So a french translation maybe returns completely different results.

6

My understanding is that the change meant that we query both labels and values. This was due to complaints that the field was not usable as non-programmer admins do not know the actual value of the enum. i.e. we have some enums like:

1=Active
0=Inactive

So in your case, I’d expect both Online + Hybrid to match here, but not p as there is no O in there. Are we saying it is matching all three / just returning everything?

I’ve setup a simple test case. I have an object that looks like this:

/**
 * @versioned false
 * @datamanagergroup test
 * @datamanagerGridFields label,test_prop
 *
 */
component {
	property name="test_prop" type="string" dbtype="varchar" maxlength=10 enum="domtest";
}

I have setup the domtest enum to be exactly as yours. I have then populated records with one each for each of the enum values:

image
image1214×762 42.9 KB

Filtering on where test_prop contains "O" gives me the result that I would expect:

image
image1392×780 42.3 KB

Is this behaviour what you are saying has changed @m.hnat ?

7

It seems to work if you use it as a single filter option, but in conjunction with another filter statement it doesn’t change the result.

Example:
Veranstaltungstyp [ enthalt ] [ "o" ] returns 10.000 records.

Veranstaltungstyp [ enthalt ] [ "o" ] and Nachname [ enthalt ] ["hnat"] still returns 10.000 records.

image

It seems, that the combined select is somehow broken and only a part of the query is generated, while all other filter statements are ignored.

8

I can reproduce this too. Will raise this and put in our critical lane:

https://presidecms.atlassian.net/browse/PRESIDECMS-2702

9

A fix for this has been released @m.hnat - patched to all effected versions (10.18 onward). Thanks for raising.