JQL is not working correctly with Empty

[syobaid9065]

JQL is not working correctly with Empty, If this is the data issue then someone from Jira should resolved it please.

[Andy Heinzer]

There is a known bug that can cause this behavior.  Please see https://jira.atlassian.com/browse/JRACLOUD-77541 for more details.

Within Jira Cloud, when you are using one or more team-managed projects that contain the same field name, in this case Dev Due Date, the JQL is getting confused because there exists another project that has that same field name where that issue cannot have a value for that other field by the same name.

If you can identify the field id for each of these custom fields, as mentioned in the bug ticket workaround section, then you could construct a new JQL query that avoids this ambiguity.  For example, if you found that the Dev Due Date field within a project with a key such as ABC, had a custom field id of 10010, you could build a JQL to find these by using a query such as

project=ABC and cf[10010] is EMPTY

If you're trying to do this across two projects, then you'd also want to know the other projects Dev Due Date field id.  If for example, project XYZ has that field name's id of 10025, then you could join up these queries to make

(project=ABC and cf[10010] is EMPTY) OR (project=XYZ and cf[10025] is EMPTY)

This query would find all the issues in either project that have their respective field by that name without a value.

I realize this is not an ideal solution for all users, but I would recommend watching the bug ticket for updates to this.

Regards,

Andy

[Mykenna Cepek]

Thanks for calling out the existing bug here, @Andy Heinzer

If you're reading this thread, this bug likely affects you, so please go vote for that bug.

I do want to observe that the workaround is undesirable for several reasons:

• This numerical custom field accessor format "cf[12345]" is user-hostile. A human can't tell what field that is without some frustrating digging. This workaround makes JQL much less readable, which complicates maintenance and troubleshooting.
• It's brittle in a few ways:
  • This JQL is useless to someone else's Jira instance, since the custom field IDs will vary by instance. Copy/paste from this thread will not work for you.
  • A Jira restore (or even import operation, such as in a migration) might break this JQL. It's fine within the same Jira instance, but not outside of it.
  • The JQL isn't portable across team-managed projects (would have to be tweaked), and can't be used in a multi-project way (e.g. Automation Rules).
  • The JQL would break when migrating data from a Team-managed project to a Company-managed project (and vice-versa).

Admittedly the fixes to some of the above issues might be pretty straightforward. But that's assuming the problem is discovered before impacting a team, that there are only a few places affected, etc.

I bring all this up to 1) encourage people to vote to fix this, 2) warn about the consequences of living with this workaround, and 3) encourage Atlassian to fix this.

[Bloompeak Support]

Hi @syobaid9065 ,

Try using date format as YYYY-MM-DD

"Dev Due Date[Date]" < 2000-01-01

[Mykenna Cepek]

You might want to report this as a bug instead of posting it in the community.

A workaround that might help is to change from using "is empty" to comparing against an ancient date:

"Start date" > "2000/01/01"

[syobaid9065]

I want to list down Empty due date, and your suggestion is not working.

[Mykenna Cepek]

Hmm. I experimented, and I cannot find another workaround for you. I also do not see this behavior in our Jira Cloud instance.

I suggest you report this to Support as a bug, and enlist their help. Be sure to include your first screenshot here, as it clearly illustrates the problem.

[Mykenna Cepek]

@Andy Heinzer identified an existing bug related to this:

https://jira.atlassian.com/browse/JRACLOUD-77541

Be sure to go there, vote for that bug, and optionally add yourself as a watcher. It's unlikely that it will get fixed without lots of votes.