-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 8.0.0, 9.4.6, 9.4.8, 9.12.15
-
Component/s: Dashboards & Reports - Reports, Issue - View Issue
-
None
-
8
-
4
-
Severity 2 - Major
-
3
Issue Summary
This is reproducible on Data Center: Yes
If an interface is bi-lingual (English and French for example), if users change the story point field (or other fields) the history will reflect the language of the user where the field was changed.
This can be challenging that in that the history is not fully translated into the users language and it also causes issues related Agile Reports (the reports reflect the last value in that language versus the actual field value).
Steps to Reproduce
- Create 2 users with 2 different default languages (I tested with English and French).
- Configure a translation for the Story Points field for the non-English language via Settings > Issues > Custom Fields > ... (for the Story Point field) > Translate.
- Create a Jira Software project (you can use the sample project data).
- Set the story points for an issue in one language for an issue.
- Login to Jira via the other user and open the same user. Then change the story points again.
- Load the history of the issue, notice that the history reflects the language of the user that originally made the change.
- If you add this issue to a sprint, close the issue and then close the sprint. If you load a Velocity Chart, you will see the report shows the last value in the history for the language of the current user.
Expected Results
We would expect that the Story Points field (this also can impact other fields too such as Rank or Sprint) would show in the history in the users default language. The Agile Reports should use values from the history or the issue without it pending the users language.
Actual Results
As noted in the steps to recreate, the history shows the field in the language of the user that made that change and the Agile Reports will leverage the last change made to these fields in the language of the user running the report.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available