-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
operator='not-in' value='' should not cause an exception #45
operator='not-in' value='' should not cause an exception #45
Comments
Thanks Ben for raising. I'll add it to the backlog :) |
I've done a bit more testing and it turns out that when the attribute being filtered is a string, it doesn't fail, it just doesn't return any records, which is perhaps even more worrying. I've written a couple of unit tests in a new test class in the Issues folder, but I don't know if I should commit these as they would break your build until fixed, or just upload the file here. I know it's not a high priority issue, so could just upload the tests here? |
Thanks Ben, that behaviour is at least confusing indeed. Please do leave the tests there, I plan on looking into these early next week. |
Here are some tests - 2 working (without value='') and two failing (with value='') - one for strings, one for optionset values |
When you build a fetchXml query using the toolbox fetchXml builder which uses the in or not-in operator, it leaves a little bit of redundant fluff in the query:
When you run an early bound query with a condition like this, CRM does not complain and just ignores the value='' bit.
When you run it in fake-xrm-easy (v9 v2 and v3) you get this exception:
System.Exception: When trying to parse value for entity van_technician and attribute statuscode: Integer value expected
I know it's a simple one to avoid, but I think it's worth raising because it took me quite a while to work out that the problem wasn't with the real integer values in the value tag, but the unnecessary value='' attribute in the condition node, so this might trip other people up as well. I couldn't see what was wrong with the query because I was looking in the wrong place, but anyway, it's a valid query as far as CRM is concerned!
I'll also raise an issue in the FXB repo.
The text was updated successfully, but these errors were encountered: