How does a query (JQL) look for non-integers in the JIRA?

Detlef Steinhäuser [Communardo] September 11, 2017

A custom field of type number field is able to store integers and non interger values. This field type shows a different formatting for users, depending on the display language. In german, for example, “0,45” and the same in the english as “0.45”.
But when I create a JQL filter, this works only in one language!!! Why the display language will not be considered here???

Display language is "German" and the following JQL works fine:

numberfield < "0,45"

With the same JQL (see above) a user will get an error if his language is "English" :-(

How can I create a filter that works in both display languages?

2 answers

0 votes
Ignacio Pulgar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 14, 2017

Have you considered using the built-in Rank field instead? The Rank field controls the vertical order of apparition of issues in any boards, either kanban or scrum, and the higher position of the issue means a higher priority.

Using Rank they will be able to change priority by dragging a card and dropping it in another position in the board. Rank can be used in JQL as a number, despite of the fact of using alphanumeric values, and therefore it supports > and < comparators.

Note that using a custom field for priorities can be a headache if they need to change the priorities manually, asit wouldn't allow them to insert an issue between two consecutive decimals without having to change many other values. Ie: inserting an issue between priority 0.45 and 0.46.

Detlef Steinhäuser [Communardo] October 6, 2017

The rank is already used for manual sorting on the board. The automatically calculated numerical value of which I speak here, is calculated with a script based on other field values.

The customer has developed a system for determining the importance of solving a reported bug.

Perhaps "priority" was not the correct translation into English. Nevertheless, the meaning for "priority" is also strongly dependent on the context.

Back to the topic: I was concerned about the fact that Jira can not deal with decimal numbers when the user language changes. Is there a solution?

0 votes
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 12, 2017

Hi Detlef,

Sorry to hear about this problem you are facing.  I did some investigation into this issue.  At first I thought this might be something to do with the way JIRA is indexing that data.  But upon further investigation, it does not appear to matter the indexing language used here. 

Instead, you are correct that the display language is the controlling factor here that changes this functionality.   Since each user profile in JIRA can override the system default language, by selecting their own language preference in their user profile, I can certainly see why this would be a problem for JIRA instances with a multi-lingual userbase.

There is a current feature request to make a change to the code in JIRA that would help with this problem.  Please see https://jira.atlassian.com/browse/JRASERVER-45545 for details.

I recommend voting, watching, and if you like please leave a comment there explaining why this feature would help in your case.   While we do not have a clear timetable for if or when this might be added to JIRA, our product management teams do watch issues like this when planning out future road maps for JIRA.  So expressing your desire for a feature like this can help our development team prioritize changes to JIRA.

 

Possible work-around:
I was thinking about this issue some more, and since we can't seem to standarized the punctuation between languages at this time, the way I was thinking to get around this issue would be to use a plugin such as the JIRA Misc Custom Fields


That plugin is able to create a calculated custom field in JIRA based off the contents of other fields.   With this ability, you could create a new custom field that has a simple formula such as

new_field = (numberfield * 100)

That way, you could then just change the JQL to be something like

new_field < 45


This way we eliminate the need for any punctuation by moving the decimal point two places and in turn removing it.

Granted this work-around would take some time to setup, but you wouldn't have to change the format of the values in your numberfield this way.  I realize this work-around really isn't ideal if you have a lot of custom number fields in your JIRA instance, but if you happen to only have one or two, this method might be helpful in working around this problem until JIRA can be updated to implement a better solution.

Detlef Steinhäuser [Communardo] September 13, 2017

Hi Andy,

thanks for your fast reply and understanding of my/the problem.

Here are some more details and why I can not use your solution – I had already suggested this to the customer.

The original request from the customer was, that JIRA should display a numeric value (range 0..1) at each task, to prioritize the tasks. The value will be calculated on the basis of other values of different fields.

JIRA can not do this, but we have Scriptrunner ;-)

The scripted field works great. (1) It is displayed in the issue view and also after an inline edit the new calculated value is immediately visible. (If a scirpt writes the value to an other field of type number, the new calculation will only be visible after a page refresh – this is due to the processing between fetching the issue from the database and the execution of the script.)

(2) The scripdet field can be used in search queries.

(3) The scripted field can be used in the card layout of a kanban board.

(4) The scripted field can not be used in the detailed view of the kanban board :-( – Workaround: an additional custom field of type number. The scripted field copies the calculation to the other field. The number field is not indexed so that it does not appear in the search and confuses the users.

Why is the field not used for everything? >> Because of (1)

Why not creating a third field for the search, which calculates numberfield * 100? >> Because the request was a number between 0 and 1. The customer does not understand why such simple things are not possible in JRIA and the change would be to complex at this point .

Suggest an answer

Log in or Sign up to answer