Wrong string representation of RangeTermFilter

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, 7.1.X, 7.2.X, Master
• Fix Version/s: 7.2.10 DXP FP6, 7.2.X, 7.3.3 CE GA4, 7.3.10 DXP GA1, Master
• Component/s: Search Infrastructure
• Labels:
  • ee-ts
  • liferay-fixpack-dxp-6-7210
• Branch Version/s:
  7.2.x
• Backported to Branch:
  Committed
• Fix Priority: 1
• Git Pull Request: https://github.com/arboliveira/liferay-portal/pull/843

1. Go to Server Admin > Script
2. Run

   import com.liferay.portal.kernel.search.filter.RangeTermFilter
   
   RangeTermFilter rangeTermFilter = new RangeTermFilter("modifiedDate", true, true, "20190529", "20200529")
   
   out.println(rangeTermFilter)
   

Expected :

{(20190529>=modifiedDate<=20200529), (cached=null, executionOption=null)}

Actual :

{(20190529>=modifiedDate>=20200529), (cached=null, executionOption=null)}

RangeTermFilter string representation is wrong, as it messed up the Operator textual representation.

Textual representation shows 

{MUST({MUST(

{(202005*01*115959>=modified>=202005*21*015506), (cached=null, executionOption=null)}

)}, ), MUST_NOT(), SHOULD(), (cached=null, executionOption=null)}

 

No value of modifed will ever met those conditions.

The filter works, however. The bug is in the textual representation, and specifically in the Operator.toString() method, that

...
else if (name.equals(LTE.name())) {
 return StringPool.GREATER_THAN_OR_EQUAL;
}
...

which is obviously wrong.

The logic of the filter is not affected by this, as later translation to elasticsearch/solr equivalents uses only the bounds and not the operator.