Query with AND "Story Points" is EMPTY does not work

[emmanuel_dolley]

Hi Community

I have an issue with a "simple" query : 

project = MYPROJECT AND issuetype = Story AND "Story Points" is EMPTY order by created DESC

returns stories with story points estimations.

I have the same behavior with Story Points[Number].

With JIRA Cloud for Sheets plugin too.

Where is my mistake ?

Thanks in advance for your support

[Bill Sheboy · Accepted solution]

Hi @emmanuel_dolley 

Are you using a Team-Managed project (formerly called next-gen) or a Company-Managed project (formerly called classic)?  You may see this if you expand the left panel and look at the bottom.

For queries, Team-Managed projects use Story Point Estimate, while Company-Managed use Story Points.  Both appear on the views as "Story Points".

Best regards,

Bill

[emmanuel_dolley]

Hi @Bill Sheboy ,

Thank you for your support.

The project is a company-managed project.

I have tested is EMPTY / in (EMPTY)  with "Story Points" /  "Story point estimate" / "Story Points[Number]". This query part is ignored.

I have tested "Story Points[Number]" = "5" and it works as expected

By the way, using another field with is EMPTY is working too.

Best regards

Emmanuel

[Bill Sheboy]

Thanks for that information, Emmanuel.  I tried that query and it works correctly for me. 

Next, please check with your site admin to learn if there is a custom field that was created with the same name as "story points".  You can also check this yourself by typing in a query, starting to type "story points" and see if there are more resulting fields than expected.  One fields value could be getting queried while the other is being displayed.

If that is not it, I wonder if what you are seeing is related to the fix Atlassian is rolling out for IS EMPTY not working for text fields which have been cleared of a previous value.

I think your next step may be to ask your site admin to submit a support ticket to Atlassian here: https://support.atlassian.com/contact/#/  As you are on a paid, standard version they should be able to create the ticket.

Once you hear back from support, please post what you learn so the whole community can benefit.  Thanks!

[emmanuel_dolley]

Thanks a lot for your help and the link to the issue.

Regarding the custom field, there is one similar, but not exactly the same (cf picture). How can I check that this custom field is the the root cause of my issue ? Is there a way without removing this custom field ?

Regarding to the " IS EMPTY not working for text fields which have been cleared of a previous value" issue, it seems the opposite of my behavior : if I have well understood in this issue, the field is no more seen as empty, even if it is. In my issue the field is seen as empty, but is not.

I will contact my site admin, as you advice me, in order to check the 1st point, and will update the thread if there is some improvement.

Thanks again.

[Bill Sheboy]

Looks like you are okay regarding any fields; the "Story point estimate" field is the one used by Team-managed (next-gen) projects to handle story points.  So no problem there.

Yes, I understood the symptom you observed is different from that defect.  What I wondered was if the fix being rolled out was causing side-effects.  I agree it is time to ask support about this one.  

Thanks!

[emmanuel_dolley]

We have received an answer from Atlassian Cloud Support. The issue seems related to JRACLOUD-76482 - Inaccurate JQL search results when using IS EMPTY operator with project-scoped fields

The workaround proposed by Atlassian Cloud Support has worked :

The original query "Story Points" is EMPTY is replaced by cf[*****] is EMPTY, (where ***** is the ID of the custom field).

The custom field ID is obtained when writing order by + first letters of the custom field name in the JQL search bar  (or using a GET /rest/api/3/field).

Thanks

[Bill Sheboy]

Thanks, @emmanuel_dolley  I wondered if that was the problem, but I thought it unlikely that a built-in custom field could cause this condition.  Looks like the design choices/challenges for team-managed projects continue to accumulate...and...

Yet another challenge with JQL not being a SQL: a SQL would have used the fields only within this scope of the selected project(s) and so the chance of field name collisions are less likely.  I am hoping they do something to reduce that possibility as this can impact everything that requires explicitly identifying the project in searches: searches, dashboards, subscriptions, roadmaps, and multi-project boards.

The lesson here appears to be:

If you use any team-managed projects in your instance, explicitly use the custom field number in any query to prevent field name shadowing.