I spent last week setting up the synchronisation between Spirateam and JIRA and, despite the limitations of the integration, its working reasonably. One of the main outstanding issues I am facing however is that when an issue is created in JIRA that has text markup (headings, bold text, coloured text etc) it comes across into Spirateam as a complete mess, and if bi-directional sync is enabled, it then makes a mess of the original JIRA text. For example, this is from an issue created in JIRA and reflected into Spirateam. *Branch:* FedR20 h1. *Steps to reproduce* # Create a new cube or open an existing cube for edit # On the dimension tab, set up 2 different categories and add fields to each: ## First Category ## Second Category # Switch to the metric tab, set up the same 2 categories (in the same order) and add fields to each. # Compare validation messages to expected results below. # On the dimension tab, add an additional First Category after the Second Category. h1. *Actual result* *Step 4:* System displays a message indicating that The First Category category is not contiguous: XXX should fall after YYY *Step 6:* System displays a message indicating that The First Category category is not contiguous: XXX should fall after YYY h1. *Expected result* *Step 4:* This validation message should NOT appear if the user reuses the same category on both tabs. *Step 6:* This validation message should appear if the user has repeated the same category multiple times within one of the two tabs. h1. *Root cause* *Step 4:* the UI sends up 4 total sets of fields: Dimension/First Category, Dimension/Second Category, Metric/First Category, Metric/Second Category. It should only send up 2 sets: First Category/Second Category** *Step 6:* In this case, the UI should send up 3 total sets: First Category/Second Category/First Category Marking as an R20 blocker since it seems to prevent saving ALL cubes that group their fields. Does anyone have any ideas as to how this can be prevented / fixed? Its not even bringing carriage returns across and Id prefer not to have to manually reformat every single JIRA issue that sycs across en-US(C) Copyright 2006-2026 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/spirateam/issues-questions/2183.aspxthreadId=2183Graeme Reynolds (graemer71@gmail.com) I spent last week setting up the synchronisation between Spirateam and JIRA and, despite the limitations of the integration, its working reasonably. One of the main outstanding issues I am facing however is that when an issue is created in JIRA that has text markup (headings, bold text, coloured text etc) it comes across into Spirateam as a complete mess, and if bi-directional sync is enabled, it then makes a mess of the original JIRA text. For example, this is from an issue created in JIRA and reflected into Spirateam. *Branch:* FedR20 h1. *Steps to reproduce* # Create a new cube or open an existing cube for edit # On the dimension tab, set up 2 different categories and add fields to each: ## First Category ## Second Category # Switch to the metric tab, set up the same 2 categories (in the same order) and add fields to each. # Compare validation messages to expected results below. # On the dimension tab, add an additional First Category after the Second Category. h1. *Actual result* *Step 4:* System displays a message indicating that The First Category category is not contiguous: XXX should fall after YYY *Step 6:* System displays a message indicating that The First Category category is not contiguous: XXX should fall after YYY h1. *Expected result* *Step 4:* This validation message should NOT appear if the user reuses the same category on both tabs. *Step 6:* This validation message should appear if the user has repeated the same category multiple times within one of the two tabs. h1. *Root cause* *Step 4:* the UI sends up 4 total sets of fields: Dimension/First Category, Dimension/Second Category, Metric/First Category, Metric/Second Category. It should only send up 2 sets: First Category/Second Category** *Step 6:* In this case, the UI should send up 3 total sets: First Category/Second Category/First Category Marking as an R20 blocker since it seems to prevent saving ALL cubes that group their fields. Does anyone have any ideas as to how this can be prevented / fixed? Its not even bringing carriage returns across and Id prefer not to have to manually reformat every single JIRA issue that sycs across Mon, 22 Jun 2020 09:55:21 -04002020-06-25T18:14:44-04:00/Support/Forum/spirateam/issues-questions/2183.aspxmessageId=3796David J (adam.sandman+support@inflectra.com) Hi Graeme The problem here is that Jira stores its text in multiple different formats: Plain Text Wiki Markup (Confluence) Markdown Whereas SpiraTeam uses rich HTML formatting throughout. So when we send issues to JIRA we have to convert them to plaintext to ensure they work on all flavors of Jira. On the reverse direction we take that plaintext and use in Spira.W We are currently planning on updating the Jira plugin to handle some of the conversion on the return direction more elegantly (maintain carriage returns, etc.) within the limits of the different JIRA formats. Regards David Mon, 22 Jun 2020 11:07:07 -04002020-06-22T11:07:07-04:00/Support/Forum/spirateam/issues-questions/2183.aspx#reply3796messageId=3798David J (adam.sandman+support@inflectra.com) We just updated the plugins on our website. The cloud sync is already updated with the improvement. Regards David Thu, 25 Jun 2020 18:14:44 -04002020-06-25T18:14:44-04:00/Support/Forum/spirateam/issues-questions/2183.aspx#reply3798