-
Bug
-
Resolution: Tracked Elsewhere
-
Low
-
5.9.11, 6.9.0, 6.9.3, 6.13.5
-
16
-
Severity 3 - Minor
-
3
-
Fixed in Jira 8.0
Closing this issue for Confluence Server and Data Center as the root cause has been resolved in Jira. JRASERVER-31977 has a workaround for Jira 7.13.x and 7.12.0 and has been fixed from Jira 8.0+. Thank you.
As for several built-in customfield-types, Confluence seems to have trouble displaying the name of a version instead of just its ID when adding a custom version-field from JIRA as column in the JIRA macro on a Confluence-page. Please see jira_macro_version_customfield_only_displays_id.png
While I can comprehend, that this is due to the fact that the JIRA Macro in Confuence pulls the data from JIRA using XML and there, only the ID is contained, it should behave exactly like the default fields for version (fixed Version, affected Version) where the names are rendered properly in the JIRA Macro on Confluence.
This renders the option of a custom version-field somewhat useless when a team relies on displaying such information on Confluence.
Tested this on Confluence 5.9.11 with JIRA 7.1.7.
Confluence JIRA Plugin version 5.7.2
JIRA Integration::Plugin version 3.0.2
Confluence and JIRA Content Connector version 1.9.0
Please let me know whether you need any additional issues.
Update and potential Workaround:
We have digged through the Velocity-templates that are used for the XML-Export of the issues and could find, that the xml-version.vm-Template handles the value differently than, for instance, the xml-multiselect.vm:
xml-version.vm
#disable_html_escaping()
#if ($value)
#foreach ($singleValue in $value)
<customfieldvalue>$!singleValue.id</customfieldvalue>
#end
#end
xml-multiselect.vm
#disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.optionId"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end
Adjusting the value of the customfieldvalue-Tag in the xml-version.vm accordingly, will fix the issue and render the version-name in Confluence instead of the version-ID, making the field useful within Confluence again. Please see jira_macro_version_customfield_after_vm_fix.png
The xml-version.vm looks like this now (on a JIRA 7.1.7):
#disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.id"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end
It would certainly be much appreciated to have your feedback whether this is a safe workaround or expected to break things somewhere else. However as it's a customfield that's merely for personal documentation, I doubt it could have any negative impact other than maybe not being imported properly when doing an xml export and import.
Thank you for your consideration.
Regards,
Philipp Sendek [Adaptavist]
- duplicates
-
-
- Closed
-
- is caused by
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Gathering Impact
-
(2 mentioned in)
[CONFSERVER-43035] Confluence doesn't display version-name but ID as value in JIRA Macro for version-customfield
| Remote Link | New: This issue links to "Page (Confluence)" [ 712625 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 621817 ] |
| Description |
Original:
(/) Please refer to
As for several built-in customfield-types, Confluence seems to have trouble displaying the name of a version instead of just its ID when adding a custom version-field from JIRA as column in the JIRA macro on a Confluence-page. Please see [^jira_macro_version_customfield_only_displays_id.png] While I can comprehend, that this is due to the fact that the JIRA Macro in Confuence pulls the data from JIRA using XML and there, only the ID is contained, it should behave exactly like the default fields for version (fixed Version, affected Version) where the names are rendered properly in the JIRA Macro on Confluence. This renders the option of a custom version-field somewhat useless when a team relies on displaying such information on Confluence. Tested this on Confluence 5.9.11 with JIRA 7.1.7. Confluence JIRA Plugin version 5.7.2 JIRA Integration::Plugin version 3.0.2 Confluence and JIRA Content Connector version 1.9.0 Please let me know whether you need any additional issues. *Update and potential Workaround:* We have digged through the Velocity-templates that are used for the XML-Export of the issues and could find, that the xml-version.vm-Template handles the value differently than, for instance, the xml-multiselect.vm: *xml-version.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue>$!singleValue.id</customfieldvalue> #end #end {code} *xml-multiselect.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.optionId"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} Adjusting the value of the customfieldvalue-Tag in the xml-version.vm accordingly, will fix the issue and render the version-name in Confluence instead of the version-ID, making the field useful within Confluence again. Please see [^jira_macro_version_customfield_after_vm_fix.png] The xml-version.vm looks like this now (on a JIRA 7.1.7): {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.id"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} It would certainly be much appreciated to have your feedback whether this is a safe workaround or expected to break things somewhere else. However as it's a customfield that's merely for personal documentation, I doubt it could have any negative impact other than maybe not being imported properly when doing an xml export and import. Thank you for your consideration. Regards, Philipp Sendek [Adaptavist] |
New:
{panel:title=Fixed in Jira 8.0|borderStyle=solid|borderColor=#6554c0|titleBGColor=#6554c0|bgColor=#eae6ff|titleColor=#ffffff}
Closing this issue for Confluence Server and Data Center as the root cause has been resolved in Jira. {panel} As for several built-in customfield-types, Confluence seems to have trouble displaying the name of a version instead of just its ID when adding a custom version-field from JIRA as column in the JIRA macro on a Confluence-page. Please see [^jira_macro_version_customfield_only_displays_id.png] While I can comprehend, that this is due to the fact that the JIRA Macro in Confuence pulls the data from JIRA using XML and there, only the ID is contained, it should behave exactly like the default fields for version (fixed Version, affected Version) where the names are rendered properly in the JIRA Macro on Confluence. This renders the option of a custom version-field somewhat useless when a team relies on displaying such information on Confluence. Tested this on Confluence 5.9.11 with JIRA 7.1.7. Confluence JIRA Plugin version 5.7.2 JIRA Integration::Plugin version 3.0.2 Confluence and JIRA Content Connector version 1.9.0 Please let me know whether you need any additional issues. *Update and potential Workaround:* We have digged through the Velocity-templates that are used for the XML-Export of the issues and could find, that the xml-version.vm-Template handles the value differently than, for instance, the xml-multiselect.vm: *xml-version.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue>$!singleValue.id</customfieldvalue> #end #end {code} *xml-multiselect.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.optionId"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} Adjusting the value of the customfieldvalue-Tag in the xml-version.vm accordingly, will fix the issue and render the version-name in Confluence instead of the version-ID, making the field useful within Confluence again. Please see [^jira_macro_version_customfield_after_vm_fix.png] The xml-version.vm looks like this now (on a JIRA 7.1.7): {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.id"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} It would certainly be much appreciated to have your feedback whether this is a safe workaround or expected to break things somewhere else. However as it's a customfield that's merely for personal documentation, I doubt it could have any negative impact other than maybe not being imported properly when doing an xml export and import. Thank you for your consideration. Regards, Philipp Sendek [Adaptavist] |
| Description |
Original:
As for several built-in customfield-types, Confluence seems to have trouble displaying the name of a version instead of just its ID when adding a custom version-field from JIRA as column in the JIRA macro on a Confluence-page. Please see [^jira_macro_version_customfield_only_displays_id.png]
While I can comprehend, that this is due to the fact that the JIRA Macro in Confuence pulls the data from JIRA using XML and there, only the ID is contained, it should behave exactly like the default fields for version (fixed Version, affected Version) where the names are rendered properly in the JIRA Macro on Confluence. This renders the option of a custom version-field somewhat useless when a team relies on displaying such information on Confluence. Tested this on Confluence 5.9.11 with JIRA 7.1.7. Confluence JIRA Plugin version 5.7.2 JIRA Integration::Plugin version 3.0.2 Confluence and JIRA Content Connector version 1.9.0 Please let me know whether you need any additional issues. *Update and potential Workaround:* We have digged through the Velocity-templates that are used for the XML-Export of the issues and could find, that the xml-version.vm-Template handles the value differently than, for instance, the xml-multiselect.vm: *xml-version.vm* {code} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue>$!singleValue.id</customfieldvalue> #end #end {code} *xml-multiselect.vm* {code} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.optionId"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} Adjusting the value of the customfieldvalue-Tag in the xml-version.vm accordingly, will fix the issue and render the version-name in Confluence instead of the version-ID, making the field useful within Confluence again. Please see [^jira_macro_version_customfield_after_vm_fix.png] The xml-version.vm looks like this now (on a JIRA 7.1.7): {code} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.id"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} It would certainly be much appreciated to have your feedback whether this is a safe workaround or expected to break things somewhere else. However as it's a customfield that's merely for personal documentation, I doubt it could have any negative impact other than maybe not being imported properly when doing an xml export and import. Thank you for your consideration. Regards, Philipp Sendek [Adaptavist] |
New:
(/) Please refer to
As for several built-in customfield-types, Confluence seems to have trouble displaying the name of a version instead of just its ID when adding a custom version-field from JIRA as column in the JIRA macro on a Confluence-page. Please see [^jira_macro_version_customfield_only_displays_id.png] While I can comprehend, that this is due to the fact that the JIRA Macro in Confuence pulls the data from JIRA using XML and there, only the ID is contained, it should behave exactly like the default fields for version (fixed Version, affected Version) where the names are rendered properly in the JIRA Macro on Confluence. This renders the option of a custom version-field somewhat useless when a team relies on displaying such information on Confluence. Tested this on Confluence 5.9.11 with JIRA 7.1.7. Confluence JIRA Plugin version 5.7.2 JIRA Integration::Plugin version 3.0.2 Confluence and JIRA Content Connector version 1.9.0 Please let me know whether you need any additional issues. *Update and potential Workaround:* We have digged through the Velocity-templates that are used for the XML-Export of the issues and could find, that the xml-version.vm-Template handles the value differently than, for instance, the xml-multiselect.vm: *xml-version.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue>$!singleValue.id</customfieldvalue> #end #end {code} *xml-multiselect.vm* {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.optionId"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} Adjusting the value of the customfieldvalue-Tag in the xml-version.vm accordingly, will fix the issue and render the version-name in Confluence instead of the version-ID, making the field useful within Confluence again. Please see [^jira_macro_version_customfield_after_vm_fix.png] The xml-version.vm looks like this now (on a JIRA 7.1.7): {code:java} #disable_html_escaping() #if ($value) #foreach ($singleValue in $value) <customfieldvalue key="$singleValue.id"><![CDATA[$xmlutils.escapeForCdata($!singleValue.toString())]]></customfieldvalue> #end #end {code} It would certainly be much appreciated to have your feedback whether this is a safe workaround or expected to break things somewhere else. However as it's a customfield that's merely for personal documentation, I doubt it could have any negative impact other than maybe not being imported properly when doing an xml export and import. Thank you for your consideration. Regards, Philipp Sendek [Adaptavist] |
| Fix Version/s | New: No-Version [ 66670 ] | |
| QA Demo Status | New: Not Needed [ 14332 ] | |
| QA Kickoff Status | New: Not Needed [ 14236 ] | |
| Resolution | New: Tracked Elsewhere [ 15 ] | |
| Status | Original: Gathering Impact [ 12072 ] | New: Closed [ 6 ] |
| Link |
New:
This issue is caused by |
| UIS | Original: 5 | New: 3 |
| UIS | Original: 3 | New: 5 |
| Support reference count | Original: 15 | New: 16 |
Hi everyone
Closing this issue for Confluence Server and Data Center as the root cause has been resolved in Jira.
JRASERVER-31977, has a workaround for Jira 7.13.x and 7.12.0 and has been fixed from Jira 8.0+.Thank you for your comments and patience with this issue. Thanks also to bandreeti for your support.
Thanks
Makisa | Senior Product Manager, Confluence Server and Data Center