Oh okay I understand. Well .. in that case how do you "OR" conditions in
the form? Do you do it selectively or do you want all "OR" or all "AND"?

On Feb 2, 2018 1:26 PM, "gil portenseigne" <gil.portensei...@nereide.fr>
wrote:

> Inline
>
>
> On 02/02/2018 11:04, Taher Alkhateeb wrote:
>
>> So it's not some SQL union but rather just a simple "OR" instead of "AND"
>> for some conditions.
>>
> Yes it's that simple, but between different fields.
>
>>
>> I was actually thinking of this problem recently but not only for two
>> options but rather multiple options.
>>
> Nice, so we are not alone meeting this issue. This improvement allow the
> "OR" to be used between multiple (2 and more) fields conditions (even
> multi-select widget). I took 2 for the example, but you can defined many
> different groups, that can contains many fields.
>
>>
>> To be more specific, our drop-down form widgets have an attribute
>> "allow-multiple" or something like that which yields a list of values.
>> This
>> cannot be currently handled by performFind and the other related search
>> services.
>>
> I confirm that performFind works with multi-select fields, if *no specific
> operator* is set :
>
> if(UtilValidate.isNotEmpty(UtilGenerics.toList(fieldValue))){
>                 fieldOp = EntityOperator.IN;
>             } else {
>                 fieldOp = EntityOperator.EQUALS;
>             }
>
> The condition will be  EntityCondition.makeCondition(myField,
> EntityOperator.IN, selectedValues)
>
>   So I think having an automatic "OR" on multiple dropdown values
>> is an important feature to implement and I would give that a +1.
>>
> The improvement concern OR condition between differents fields :)
>
> Thanks !
>
> Gil
>
>
>> On Feb 2, 2018 11:44 AM, "gil portenseigne" <gil.portensei...@nereide.fr>
>> wrote:
>>
>> Yes, actually using form widget with performFind services do not offer a
>> way to union two search criteria.
>>
>> Exemple : i want to find all communicationEvent that are in Bounced status
>> *or* that contains something in note field. (very specific, strange, thats
>> why)
>>
>>
>> By default all search criteria are managed in EntityCondition like :
>>
>> List<EntityCondition> allDefaultSearchCriteria =
>> UtilMisc.toList(criteria1Condition, criteria2Condition ...);
>>
>> The resulting final condition would result as :
>> EntityCondition.makeCondition(allDefaultSearchCriteria,
>> EntityOperator.AND)
>>
>>
>> With the enhancement, by regrouping two fields with field1_grp =
>> 'groupKey'
>> and field2_grp = 'groupKey'
>>
>> the following condition is added to the other default ones like :
>>
>> allDefaultSearchCriteria.add(EntityCondition.makeCondition(U
>> tilMisc.toList(field1Condition, field2Condition), EntityOperator.OR));
>>
>> I hope this will be clearer.
>>
>>
>> On 01/02/2018 21:07, Taher Alkhateeb wrote:
>>
>> Hi, perhaps if you share the idea of how to translate it to the entity
>>> engine conditions then we'd be better informed?
>>>
>>> On Feb 1, 2018 6:30 PM, "gil portenseigne" <gil.portensei...@nereide.fr>
>>> wrote:
>>>
>>> Hello,
>>>
>>>> In a customer project we met a very specific need in a search screen
>>>> that
>>>> offer search criteria that must unions and not intersect.
>>>>
>>>> I propose this improvement in OFBIZ-10195, https://s.apache.org/sjW1
>>>> but
>>>> i'm wondering if any of you ever met such need ?
>>>>
>>>> Is that worth to be commited in the code base ? I tend to say yes, but
>>>> i'd
>>>> like to hear the community out about this.
>>>>
>>>> Thanks !
>>>>
>>>> Gil
>>>>
>>>>
>>>>
>>>>
>>>>
>

Reply via email to