Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-33966

Race condition occurs between JIRA and plugins with i18n translation

XMLWordPrintable

      Plugins like GreenHopper and Service Desk which "do stuff" on JIRA start-up/plugin enabled event are suffering from a race condition with JIRA's I18n system. The plugin can (rightfully) request the translation of a key before it's i18n plugin modules have been registered with JIRA. This causes the translation to be returned as the raw key instead of the message.

      This is affecting customers today.

      Workaround

      For GreenHopper, please see the workaround steps as detailed in GHS-9193.

          Form Name

            [JRASERVER-33966] Race condition occurs between JIRA and plugins with i18n translation

            Dave C added a comment -

            Thanks edalgliesh

            Dave C added a comment - Thanks edalgliesh

            Eric Dalgliesh added a comment -

            There's nothing more that can be done in JIRA for now, so I'm resolving this issue again. Further work is tracked at GHS-9702.

            If you are a customer experiencing this issue and GHS-9702 has not yet been resolved, please contact https://support.atlassian.com who should be able to provide you with a way to fix your system up.

            Eric Dalgliesh added a comment - There's nothing more that can be done in JIRA for now, so I'm resolving this issue again. Further work is tracked at GHS-9702 . If you are a customer experiencing this issue and GHS-9702 has not yet been resolved, please contact https://support.atlassian.com who should be able to provide you with a way to fix your system up.

            Dave C added a comment -

            Upgrading an instance that is affected with this behaviour unfortunately doesn't fix the problem - that is, there doesn't appear to be an upgrade task that converts the affected fields from the i18n values to their translated values.

            If the root cause is fixed, is there some way of updating already affected data?

            Replicated by taking a 6.0.3 instance and upgrading it to 6.0.6.

            Dave C added a comment - Upgrading an instance that is affected with this behaviour unfortunately doesn't fix the problem - that is, there doesn't appear to be an upgrade task that converts the affected fields from the i18n values to their translated values. If the root cause is fixed, is there some way of updating already affected data? Replicated by taking a 6.0.3 instance and upgrading it to 6.0.6.

            Rick Schultz added a comment - - edited

            Agree with importance of this. I'm rolling out to a new team and it has resulted in confusion. Hopefully, it can resolved soon.

            I upgraded to 6.0.6 to no avail on the existing instance. Following the manual steps in GHS-9193 to correct the fields worked sufficently to get our instance cleaned up.

            Rick Schultz added a comment - - edited Agree with importance of this. I'm rolling out to a new team and it has resulted in confusion. Hopefully, it can resolved soon. I upgraded to 6.0.6 to no avail on the existing instance. Following the manual steps in GHS-9193 to correct the fields worked sufficently to get our instance cleaned up.

            Thierry Lach added a comment - - edited

            I agree with Leon and Sven. Jira/Greenhopper are applications we intend to be used by less technical people in our organization who also happen to have their fingers on the purse strings. This problem reflects on our professional image and as such we cannot roll out our new installation until this is resolved. Technically the application is usable, but in practical terms it is not.

            Thierry Lach added a comment - - edited I agree with Leon and Sven. Jira/Greenhopper are applications we intend to be used by less technical people in our organization who also happen to have their fingers on the purse strings. This problem reflects on our professional image and as such we cannot roll out our new installation until this is resolved. Technically the application is usable, but in practical terms it is not.

            Sven Schott added a comment -

            This might not prevent JIRA from working but it sure does affect productivity. We are trying to convince users that Greenhopper is useful to us but it is difficult when usability problems like this crop up without a satisfactory solution or workaround. I hope this is addressed soon.

            Sven Schott added a comment - This might not prevent JIRA from working but it sure does affect productivity. We are trying to convince users that Greenhopper is useful to us but it is difficult when usability problems like this crop up without a satisfactory solution or workaround. I hope this is addressed soon.

            Dave C added a comment -

            Is there any workaround for this issue that we can provide to customers affected by it until the bug can be fixed?

            Dave C added a comment - Is there any workaround for this issue that we can provide to customers affected by it until the bug can be fixed?

            Leon Liu (ease solutions) added a comment -

            Hi guys,
            This issue is our showstopper.
            Thanks
            Leon

            Leon Liu (ease solutions) added a comment - Hi guys, This issue is our showstopper. Thanks Leon

            Eric Dalgliesh added a comment -

            The priority field is a misnomer - it measures severity according to strict criteria and does not represent importance. The definition of critical is "crashes, loss of data, severe memory leak". This issue is, at its worst, a display issue where some strings are not displayed. As such the highest priority it can have is Major (that is, "major loss of function").

            Eric Dalgliesh added a comment - The priority field is a misnomer - it measures severity according to strict criteria and does not represent importance. The definition of critical is "crashes, loss of data, severe memory leak". This issue is, at its worst, a display issue where some strings are not displayed. As such the highest priority it can have is Major (that is, "major loss of function").

            Michael Tokar added a comment -

            edalgliesh I really don't see how this is a "Minor" issue. We have three bugs reported for it already, each with linked support cases. Furthermore, this bug is caused by a regression in JIRA which jwinters thought was fixed in JIRA 6.0.2.

            James, what's the latest on this?

            Michael Tokar added a comment - edalgliesh I really don't see how this is a "Minor" issue. We have three bugs reported for it already, each with linked support cases. Furthermore, this bug is caused by a regression in JIRA which jwinters thought was fixed in JIRA 6.0.2. James, what's the latest on this?

              edalgliesh Eric Dalgliesh
              mtokar Michael Tokar
              Affected customers:
              8 This affects my team
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: