• 217
    • 42
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      We have a custom field that is of number type. Two problems:

      1. When the field is printed out it gets printed with commas. So 1234 would become 1,234. Is there a way to disable this?

      2. Entering data in the field does not permit commas. This is a strange inconsistency - I can't copy-paste a number from one form to another.

      Jira needs to pick which way it wants to go on printing/accepting commas in its custom number fields. I'd recommend getting rid of it entirely, as it's very distracting when we use it for build numbers or changelist numbers.

      Workaround

        1. screenshot-1.png
          screenshot-1.png
          31 kB
        2. view-number.patch
          0.4 kB

            [JRACLOUD-7582] Inconsistency in rendering of number fields

            Fully agree that visual display, data acquisition by typing/pasting into the field should be consistent. Some numbers should simply not be transformed, but entering them as text is also not a solution. Display (renderer) should allow at least for customization of the display (with or without separators, etc.). Non-integers a bonus.

            Lars Vilhuber added a comment - Fully agree that visual display, data acquisition by typing/pasting into the field should be consistent. Some numbers should simply not be transformed, but entering them as text is also not a solution. Display (renderer) should allow at least for customization of the display (with or without separators, etc.). Non-integers a bonus.

            It is ridiculous to bring out a product that does not support international number/currency support anno 2024. How difficult can it be to store numbers with decimals and show them according to the international standards??! Even dBase did better in the early days...

             

            Come on Atlassian. I am sure you can do better then this.

            Hans.Maarten.Vink added a comment - It is ridiculous to bring out a product that does not support international number/currency support anno 2024. How difficult can it be to store numbers with decimals and show them according to the international standards??! Even dBase did better in the early days...   Come on Atlassian. I am sure you can do better then this.

            The trouble is, that the comma doesn't even fit for countries that are using dots to separate the three digits. I do not see a reason to remove the seperators. It is just a visual effect to read a currency or bigger number more comfortable. Unless there is a good solution within a renderer of the field or anything, Atlassian should just remove the comma completly.

            Benjamin Horst added a comment - The trouble is, that the comma doesn't even fit for countries that are using dots to separate the three digits. I do not see a reason to remove the seperators. It is just a visual effect to read a currency or bigger number more comfortable. Unless there is a good solution within a renderer of the field or anything, Atlassian should just remove the comma completly.

            The problem is that Jira assumes every number field is a count of a number. Like 500,000 five-hundred-thousand things / pounds / dollars. So every number ends up being separated by commas.

            Addding reg-ex validation to an existing text field is a convoluted and stupid workaround. Why not just either:

            • Create separate field types for number:
              • Count / Currency
                • This is stuff that you might want to perform sum functions on.
                • Show total of thing
              • Numeric value
                • This could be text field with the regex validation in it anyway but the user wouldn't need to manually configure this functionality.
            • Create a different renderer
              • Like we have with text paragraph fields
              • One for a count and one for a numeric value
              • Users then get to choose how they want the value displayed

            Separately, these things tend to get to about a 500-1000 angry admins until Atlassian take much notice. This one isn't even assigned to anyone yet so it feels like shouting into a closed door.

            David Meredith added a comment - The problem is that Jira assumes every number field is a count of a number. Like 500,000 five-hundred-thousand things / pounds / dollars. So every number ends up being separated by commas. Addding reg-ex validation to an existing text field is a convoluted and stupid workaround. Why not just either: Create separate field types for number: Count / Currency This is stuff that you might want to perform sum functions on. Show total of thing Numeric value This could be text field with the regex validation in it anyway but the user wouldn't need to manually configure this functionality. Create a different renderer Like we have with text paragraph fields One for a count and one for a numeric value Users then get to choose how they want the value displayed Separately, these things tend to get to about a 500-1000 angry admins until Atlassian take much notice. This one isn't even assigned to anyone yet so it feels like shouting into a closed door.

            Ian Brown added a comment -

            This is so annoying, at least let us have a choice, we are using a number field for a caseid. I don't want a comma in it.

            Ian Brown added a comment - This is so annoying, at least let us have a choice, we are using a number field for a caseid. I don't want a comma in it.

            This is a great question! ^^^^

            James Robey added a comment - This is a great question! ^^^^

            Jacques B added a comment -

            This issue has 200 votes. How many are required for it to be considered?

            Jacques B added a comment - This issue has 200 votes. How many are required for it to be considered?

            Jacques B added a comment -

            Jacques B added a comment - https://support.atlassian.com/requests/JST-774072

            Jacques B added a comment -

            Would be great if the decimal separator can be localized as well. In some countries a comma is used for this and when exporting to Excel the data is useless unless you do a find and replace

            Jacques B added a comment - Would be great if the decimal separator can be localized as well. In some countries a comma is used for this and when exporting to Excel the data is useless unless you do a find and replace

            I would love a reply feature to comments! All the new digital platforms for WFH have an option (Slack, Teams, etc.)

            Caleb Castro added a comment - I would love a reply feature to comments! All the new digital platforms for WFH have an option (Slack, Teams, etc.)

              Unassigned Unassigned
              46dd16050868 Scott Bilas
              Votes:
              258 Vote for this issue
              Watchers:
              136 Start watching this issue

                Created:
                Updated: