Discussions

Hi,
I have discovered a case-sensitive bug during my development of an add on.

1. When I run my API get request for a material by the Item number, Let's say the Item number in ServiceM8 is 'LABOUR', but my GET request has item number as Labour; With the filter equal to, I get no result.

2. my next logical step is, I first need to create this material before adding it to the job. So i create up the data object.

3. When I then go to 'Create' the material using the end point material.json with posted data that has the item number as 'Labour', Guzzle returns a 400 bad request error from ServiceM8.

4. I then log in to ServiceM8, and update the material item to Labour, and rerun step 1 and voila my GET material by Item Number returns a uuid, and I know that I don't need to create one.
   Alternatively if i delete the material then I run steps 1 through 3 without any issues.

The issue:
What I believe is that during a 'create' the validation that is taking place, isn't the same as what is happening during the GET request.
The 'create' is not performing a case sensitive validation, and so, it is finding the material and returning a 400, where the GET is returning a 200 because it is performing a case-sensitive validation and finding no results.

This makes it difficult when working with clients who have already created their own materials, and will have either casing or mismatched casing in their materials item numbers.

Ideally, it would be preferred to operate where a compare is non-case-sensitive, and then in the filter we can overwrite, or vice versa.