JQL endpoint returns null for 0 values in custom fields

[Shane Cyr]

When using the /rest/api/3/search/jql endpoint to fetch data from a "number" type custom field, issues with a value of 0 for that field are returned as null. Other values come through as expected.

When using the /rest/api/2/issue/ endpoint for individual issues, the value comes through correctly as a 0.

[Sunny Ape]

Hello @Shane Cyr 

I can't replicate that.

Both those endpoints are correctly reporting the value of 0.0 for a custom number field set to the value of '0' (zero). They will only report a value of null if the field has no value (is empty).

Also, the v2 and v3 versions of the same endpoints all agree with each other.

[Shane Cyr]

And yet...

Would it make any difference that I'm on a team-managed project?

[Sunny Ape]

And yet...

And yet... what?

Would it make any difference that I'm on a team-managed project?

Nope.

Have a colleague peer review your work, as you're probably just doing something basically wrong, such as not referencing the same Work Item.

[Shane Cyr]

I've already done that, we are seeing different results between a batch response and fetches for individual issues. I did see both versions of your initial reply, can you tell me anything about what changed to result in the turnaround in your edit?

[Sunny Ape]

You are now using the word 'we' in your sentences, which infers you are part of a team or group of developers. Is every single person in your team able to independently replicate the exact same problem?

I changed my initial response because I double checked my work and found it was just me making a mistake, not the APIs.

If you want anyone to stand any chance of replicating what you are claiming, you need to provide INFORMATION! Without that, all you've done is make a claim without PROOF.

1. How are you making the requests. Using what language, libraries, toolset?
2. What authentication method are you using?
3. What is the entire request path including all the parameters and their values?
4. What are the actual JSON responses for queries against ONE specific Work Item and only that ONE specific custom field?
5. Do you get identical results using your API test tool?

[Shane Cyr]

I gave a response to your advice. And I assumed you had made a mistake, which is why I was asking what it was, in the hope that perhaps I was making the same one.

I apologize for apparently making this quite difficult — appreciate your time and consideration, but I think we're done here.

[Bill Sheboy]

Hi @Shane Cyr 

When I try that for a team-managed project (TMP), custom number field, I get 0, as described by @Sunny Ape 

Would you please post an image of that custom field's configuration in the TMP, including any formatting options you are using? (e.g., currency, percentage, different units, etc.)

Kind regards,
Bill

[Shane Cyr]

Sure, here it is

[Bill Sheboy]

Thanks for that information, and... 

Have you confirmed the field you are seeing in the endpoint response is that same field by comparing the custom field ID value?  I have noted other questions / posts where people had two different fields with the same name (one company-managed / global scope and another TMP) and were observing the wrong one in the data.

If that is not the cause, I am out of ideas on this one.

[Shane Cyr]

Yeah, unfortunately we've confirmed that we're looking at the right fields, the purpose of this is to bring it all into a spreadsheet and in pulling together a workaround I'm doing a bulk fetch and then augmenting it with scripted individual fetches where there's no value, into a new column. The values after doing that all match what's expected, it's just dreadfully inefficient.

Thank you for your thoughts.