Remove comma from numeric field

[Kathrine Lauritzen]

Please tell me, I can remove the comma automatically inserted in the numeric custom field in Jira. I am using OnDemand and am therefore unable to use some of the obvious solutions found on the net

[Andy Heinzer · Accepted solution]

Hi everyone,

I wanted to update this old thread.  I have create a ticket that seeks to give end users this ability to choose their own separator (or lack of one) for this over in JRACLOUD-75109.  I can certainly understand why some users would want to change this behavior.  Please vote on this issue if this is something that you would like to be able to choose within Jira Cloud.

Jira Cloud has the ability to show number fields without a comma, however it's not a specific setting that you can just enabled/disable today.  Instead the way these numeric fields are being displayed to each user is bound to the end user's selected language and region.  In Atlassian Cloud products today, each end user can select their own language by going to https://id.atlassian.com/manage-profile/account-preferences

These account preferences extend to all Cloud sites your account is using.  For example, English (US) will default to showing number values with more than 3 digits to always have a comma to separate the thousands.  However if you change your language to another value, such as Deutsch, Español, Nederlands, Dansk for examples, you will notice that numeric custom fields will instead show with a period . instead of a comma as the separator.  Russian, for a different example, uses neither a comma, nor a period, but instead just leaves a space as the separator.  After making a change like this you would then have to refresh the Jira issue in order to see this change.

But I can certainly see why users might want to be able to customize this behavior outside the language selection.  I don't speak Russian so this is not exactly a work-around that all users can feasibly follow.  That said, I wanted to make others aware that there is a way to potentially do this to meet your own region's standards in case you happen to be using the default of English. 

Thanks

Andy

[Callum Carlile _Automation Consultants_]

Thanks for this @Andy Heinzer, though it says in the linked ticket that when English is the selected language, large numbers will appear as 5,432.

My Jira account is using English (UK) as the language but large numbers aren't separated by a comma (which we would like, as the numbers relate to currencies) - is this expected behaviour? Would changing the language to English (US) force the comma?

[Andy Heinzer]

@Callum Carlile _Automation Consultants_ In both Account preferences of English US and English UK, number fields are using commas to separate thousands values.  However if these custom fields are not number fields, but rather some kind of custom field type, such as a text field, then these values would never be expected to display any separators.  I would want to confirm the custom field type here first.

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

You can't change this in JIRA onDemand as it involves editing some system files.

[Deleted user]

Hi, just checking in to see any progress as we face the same issue, the number showing in 5,555 for 4-digit with comma; wonder any solution not to use 1000 separator ? 

The number we need is created during data migration, and somehow it cannot be searched in right top corner, either. 

cc @Kathrine Lauritzen  @Jobin Kuruvilla [Adaptavist]  @Nic Brough -Adaptavist- @Brant Schroeder

[Deleted user]

just wonder how to resolve ',' issue completely in year 2017 or 2018 :-) 

[Nic Brough -Adaptavist-]

It's not an "issue" - most humans prefer to see the separators!  So, it's not changed.

[Deleted user]

oh, even though that is driven by 1000 separator ?  :-) I see your point, if we use number for currency, that is perfect, thousand, million

thank you for sharing your thought, Nic. 

[Deleted user]

it would be great not to see ',' 

[Nic Brough -Adaptavist-]

That's excel, nothing to do with Jira

[Deleted user]

right, that is what we wish for -  to use or not to use ',' :-)

[Deleted user]

Thank you though,  and I also got some feedback regarding quick search,  I was told that no way to conduct number quick search, with ',' or without :-)  (not by query line)

[James Cope]

How is this the accepted answer? I need to suppress commas, regardless of what anyone says and the logic behind their argument. I can do this with every piece of software I use -- except for this one. Do I need to open a new thread since 'cannot be done' seems to be the order of the day on this one?

For the record, it's not what we have to say here. It is how we say it. Some of you could use a lesson in this little thing called TACT. Of course, now that I have descended into the muck, I'm going to Linkedin Learning now to find that class myself.

[Richard Getz]

@Nic Brough [Adaptavist] "most humans prefer to see the separators!  So, it's not changed."

What a narrow minded comment. What about numbers that don't have commas, such as product numbers, account numbers and the sort. Having commas changes the functionality of that number. 

[Nic Brough -Adaptavist-]

No, you're falling into a very narrow mindedview yourself there.

Think about it - product numbers, account numbers and other identifiers like that are not numbers, they are strings that happen to be constrained to  numbers.  If my bank account "number" was ABGORB32 it wouldn't be any better or worse than 71153622. 

If you don't want separators in your fields, then use a text field.  Separators are incredibly useful for humans when handling numbers, and I stand by "most humans prefer to see the separators", because it's inarguably correct.

[Richard Getz]

@Nic Brough -Adaptavist- Every other software has a checkbox to enable/disable this option.... but Jira. Including Excel, arguably one of largest numbers software on the planet. 

Bank accounts are ALWAYS numbers so no, they are not strings and no, they do not have commas separators. 

Phone numbers are just numbers. SSN are just numbers, EIN numbers are numbers. Shall I go on? Do YOU want to think about it a bit more?!

[Nic Brough -Adaptavist-]

<sigh> No, they're not numbers, as I've already pointed out. 

[Martin Hilbig [team neusta]]

Forcing a format that is not universally used is really bad practice. 

Using a text field if you want an integer is a really bad practice:

• it's useful to be able to order filter results in numeric order
• it's useful to be able to filter for an integer range (corresponding to a changelist)
• it's a soft validation check that the correct information is being entered (value must be an integer)
• indexing text fields versus integer fields impacts performance

The international consensus also shuns the comma or period:
"Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. For this reason, ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign"

But yeah, after 3 years of browsing this forums, I would be genuinely surprised not to find Nic here telling people how outrageous and entitled it is to have requirements that exceed current offering...

[Virginia Pino]

Consulta, los identificadores que tengo deben ser números sin separadores, por lo cuál según la lógica de Nick debería ser un campo texto, pero si es así ¿Cómo hago para que no ingrese datos alfanumericos? ¿Existe algún tipo de validación?

[Joshua Balsillie]

The only alternative I have found is that you need to use a Text Field.

You may be able to add custom Triggers, Conditions and/or Validators to your flow for ensuring the number format is correct in your project's Workflow. Quite a bit of work for a simple number field but that's what I would do if you need a certain level of accuracy.

Can we all just agree that the number field should not have comma separators, and Jira should either add the comma as an option or create a currency field (hopefully one that supports more than just the western standard: $1,000,000.00.

Example currency format in France: 1 000 000,00€

• Comma is used instead of a decimal
• Spaces are used instead of commas for decimal numbers

[Joe Pitt]

People, @Nic Brough -Adaptavist- doesn't work for Atlassian. He is just saying how it is implemented. And I agree, humans like to see the separators. It makes it easy to see the magnitude.