Skip Navigation LinksHome Page
I spent last week setting up the synchronisation between Spirateam and JIRA and, despite the limitations of the integration, it's 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? It's not even bringing carriage returns across and I'd prefer not to have to manually reformat every single JIRA issue that syc's across
Hi Graeme
The problem here is that Jira stores its text in multiple different formats:
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
We just updated the plugins on our website.
The cloud sync is already updated with the improvement.
And if you have any questions, please email or call us at +1 (202) 558-6885
