Even uit mn hoofd: dit lijkt me conflicteren met het feit dat filters sowieso al komma gescheiden zijn. Icontains zou dan ook geen kommas ondersteunen.

Volgens mij kan je doen: bla__icontains__x,bla__icontains__y

Ik vermoed ook dat we uitkomen op de discussie: AND versus OR en uiteindelijk moeten we SQL implementeren in query params :)

Ik zie inderdaad dat https://objecten.dev.kiss-demo.nl/api/v2/objects?data_attrs=naam__icontains__Advies&data_attrs=naam__icontains__support+en+kennis+%28ASK%29 het verwachte resultaat geeft.

@joeribekker op basis van je reactie twijfel ik of het probleem helder is: we willen kunnen zoeken op teksten waarin een komma voorkomt. De komma maakt gewoon deel uit van de zoekopdracht.
Het doel is dus niet om door gebruik van komma's meerdere AND/OR parameters mee te kunnen sturen oid.

Dat was dan niet helder :)

Als je het encode verwacht ik wel dat het zou werken, maar dat is dus niet zo?

In het issue worden een aantal variaties beschreven met encodering die we hebben uitgeprobeerd. Die werken niet.

Nee, deze query geeft ook die melding over not enough values terug
https://objecten.dev.kiss-demo.nl/api/v2/objects?data_attrs=naam__icontains__Advies%2C+support+en+kennis

En we zijn opzoek naar een object waarvan de naam is: "Advies, support en kennis"

We've analyzed the issued and confirm that it's a bug, and percent encoding doesn't solve the issue

This issue is considered a blocking issue for the release of PodiumD 3.0 for Deventer. We would like to align on planning of this issue and a next release of Objects.

Good to see this is picked up!
Two follow-up question:

• What is the release planning for Objecten? (heard this is already answered and will be added to release end of this month)
• Is this a fix that only allows specifically for comma's or does this more broadly allow for punctuation marks? If so, which would be supported?

Discussed: Anna is trying to see if we can parse it differently, so we know whether its a variable separation or a "comma in a value" case. If that doesnt pan out, we're looking into a env var to enable different query param behaviour that requires you 1 key/value pair per "data_attrs" param.

Removed "bug" label since it's explicitly stated in the OAS that commas are not supported:

Normal usage:

?data_attrs=naam__icontains__Anna,last_name__icontains__Shamray

What they want:

?data_attrs=departmentname__icontains__Support, advice and shizzle

In the PR there are 4 options. We picked option 1 but with a sligh change: To prevent issueing a new major release, we add a new query param (data_attr so no "s") with the behaviour to only allow 1 key/value pair per query param. This new query param can be used multiple times and thus allows for ",".

So, do I understand correctly that, with the next release, we should be using:
?data_attr=departmentname__icontains__Support, advice and shizzle or
?data_attr=departmentname__icontains__Support%2C+support+and+shizzle?
(I am very much in favour of a department of shizzle)

And , in light of @mariusvandam 's question, does that also mean we can use any type of punctuation, except maybe double underscores?

Yes, it should support space, comma and other punctuation characters (except double underscore and url reserved characters)

At this point our code uses data_attrs=naam__icontains__[value]
But we have to change this to data_attr=naam__icontains__[value], right?
Then I will create an issue on our own backlog to address this.

If value contains commas then yes, if not you can keep using the old query param (data_attrs)

Thanks for confirming! And our values can contain comma's, unfortunatly ...