parseCEL method is not working for does not contain, does not begin with, does not end with, not in
Closed this issue · 3 comments
React Query Builder version
No response
Platform
No response
Description
I have converted the RuleGroupType to CEL Expression using formatQuery(query, "cel") method, it is working fine. When i try to convert the CEL Expression back to RuleGroupType using the parseCEL method, the RuleGroupType is not as same as the initial RuleGroupType. Operators which are not working when converting CEL Expression to RuleGroup Type: does not contain, does not begin with, does not end with, not in
- This is the query generated when converting to RuleGroup Type to CEL Expression : field == "marks" && (!value.startsWith("68")).
- When converting it back to Rule Group type using parseCEL getting this value: field == "marks"
Reproduction
Construct any query which consists of !(not) in front of it like this !value.startsWith("68") when converting to CEL Expression. You can do it by selecting any of these operators: does not contain, does not begin with, does not end with, not in.
Then try to convert the same CEL expression to RuleGroupType, you can find only the expression which doesn't include these operators
Expected behavior
No response
Additional information
No response
I can reproduce the behavior with your query.
The rootcause seems the position of the !
.
In your query, it's inside the brackets.
Added some STRs, because what i assumed is wrong.
If you create the same query via the demo ui, you get the following query.
firstName == "firstname" && !(lastName.startsWith("68"))
If you import the generated CEL query, you get the following result:
If you import then the generated query:
firstName == "firstname" && (!lastName.startsWith("68"))
The error occurs also if you do not use the brackets around the second part:
firstName == "firstname" && !lastName.startsWith("68")
Thanks for the investigation @noxify! This definitely seems like a fixable bug. Exported queries should be importable as is.
I'll take a stab at it soon...unless someone else wants to have a go.
I just got around to looking at this over the weekend. Funny enough, I had put a // TODO:
comment to fix this in the test file a long time ago:
Anyway, #689 should fix the issue. You can try out the new parseCEL
behavior in the preview website demo or a sandbox with the new build.