Hi Federico,
I believe this originates from a support issue I have been assisting with this past week.
In that, we logged a defect for the behaviour, but it isn't related to CLRT-54839. The one we logged for this is CLRT-67899.
The workaround I provided for this, was to take advantage of an enhancement request in 12.1.2 and above that gives a secondary method for WSDL query filtering on selective parameters. It requires a change to both the query and the SOAP request you're sending.
In the WHERE clause of your query, you would add a condition like this:
AND inv.name in (@WHERE:PARAM:USER_DEF:STRING_LIST:projnamelist@)
(Note the data type _LIST here is what enables this capability).
Then in the SOAP request you would replace your filter with one like this:
<quer:param_projnamelist>project1,project2</quer:param_projnamelist>
As is, that would be fine, but there is a difference in behaviour to the filter it replaces because it makes it required in the query in order for it to work, if you don't supply this filter, then you get no results (instead of all as before).
If you also want it to provide all results when no filter is supplied, the WHERE clause in the query needs to instead be able to check when the parameter maybe a comma separated list or a single null value, like this:
AND (inv.name in (@WHERE:PARAM:USER_DEF:STRING_LIST:projnamelist@) OR
greatest(@WHERE:PARAM:USER_DEF:STRING_LIST:projnamelist@) is null)
This is OK for Oracle systems and now without the filter in the SOAP request, you would get all results as normal, and with the filter, just the results you desire. SQL Server does not natively support the greatest() function though and so some other alternative function that accepts any number of input parameters and chooses one is needed instead.
Please note that there is no in suffix to the SOAP request filter parameter, and that it works with both single value or multi-value (comma separated) filter entries. It is prefixed with param though, as are other @WHERE:PARAM:...@ NSQL construct parameters.
The drawback with this method of course is that you have to add a WHERE clause entry like this to the query for each parameter you want to filter on, but as a workaround it may suffice where absolutely needed until the defect can be corrected again.