rmbolger
commented
9 months ago Hi @merddyin. Thanks for reaching out. The Infoblox WAPI is indeed largely case sensitive (to the dismay of many, myself included). Even the username in your login credential is case sensitive. In filters, both field names and values are case sensitive. Though some fields support modifiers that can make the value insensitive or effectively insensitive via regex. The Infoblox supplied WAPI docs don't really call this out explicitly either that I can find. It's just kind of a hard edge that folks inevitably run into and learn from.
Unfortunately, the module can't reliably smooth this out on behalf of the user by automatically lower-casing field names because not all field names are lowercase (most notably extensible attributes). I can definitely add notes in the help though. That's a great idea.
Issue Description
When attempting to use data gleaned from places such as AD to then perform lookups by dynamically providing the values to the Filter parameter, queries do not error, but fail to return results when any of the values supplied contain upper-case letters. While this type of dependency may be a known quantity for people specializing in Infoblox, it is not consistent with standard PowerShell behaviors, which default to case insensitive. My assumption here, is that the casing would have to match whatever appears in the record inside Infoblox, in which case querying using data from other systems would be difficult if not outright impossible.
Expected Behavior
If the query requires everything to be in lower case, I would expect the cmdlet to handle conversion of the string to lower case within the code, thus avoiding the user needing to be aware of specialized handling.
If, instead, the API is fully case sensitive and requires a matching case on all characters, I would think this should be called out in the help for the filter parameter.