Loading...

Details

Type: Bug
Resolution: Unresolved
Priority: Low
Fix Version/s: None
Affects Version/s: 6.0.7, 6.1.1
Component/s: Macros - Jira Macros
Labels:
- bugfix
- jim-a
- pse-request

Support reference count:
16
Symptom Severity:
Severity 3 - Minor
UIS:
4
Bug Fix Policy:
View Atlassian Server bug fix policy

Description

Problem summary

The JIRA Issues Macro can fail to render in Confluence when a contains special characters that are not XML-safe. This issue was discovered when such a character was found in a field provided by a third-party JIRA plugin. While in JIRA this issue displays fine, Confluence was not able to render the issue.

Confluence should sanitize invalid XML characters so that the macro is not impacted by characters it cannot render.

Steps to reproduce

Install JIRA 7.2.7 + Install Confluence 6.0.7 and create an Applink between the two apps
In JIRA, install Zephyr for JIRA plugin
Create a project and a new issue of type "Test"
In the issue, add the following to the "Test Step" field (provided by Zephyr), which is the special character representing "Shift-In":
```
&#15;
```
In Confluence, create a test page with a JIRA Issues Macro which searches for the above JIRA project
Select "Labels" to be one of the fields returned
Save macro and publish page

Expected results

Confluence renders the macro successfully

Actual results

Confluence shows the following error in the UI:

Data cannot be retrieved due to an unexpected error.

Confluence logs show the following stacktrace:

2017-07-13 16:02:00,072 ERROR [JIM Marshaller:thread-16] [extra.jira.helper.JiraExceptionHelper] throwMacroExecutionException Macro execution exception: 
 -- url: /confluence/display/SR/child | page: 3604487 | traceId: b0b4e1173e350e37 | userName: admin | referer: http://localhost:5611/confluence/pages/resumedraft.action?draftId=3604488&draftShareId=bcfe5fcf-9f6d-4363-bf27-d3a1c06dcb93 | action: viewpage
java.lang.RuntimeException: java.io.IOException: Error on line 38: An invalid XML character (Unicode: 0xf) was found in the CDATA section.
	at com.atlassian.confluence.extra.jira.JiraIssuesManager$ByteStreamBasedSupplier.get(JiraIssuesManager.java:166)
	at com.atlassian.confluence.extra.jira.JiraIssuesManager$ByteStreamBasedSupplier.get(JiraIssuesManager.java:146)
	at com.atlassian.confluence.extra.jira.JiraIssuesManager$Channel.getChannelElement(JiraIssuesManager.java:116)
	at com.atlassian.confluence.extra.jira.JiraIssuesMacro.setupContextMapForStaticTable(JiraIssuesMacro.java:1029)
	at com.atlassian.confluence.extra.jira.JiraIssuesMacro.populateContextMapForStaticTable(JiraIssuesMacro.java:961)
	at com.atlassian.confluence.extra.jira.JiraIssuesMacro.createContextMapFromParams(JiraIssuesMacro.java:479)
	at com.atlassian.confluence.extra.jira.JiraIssuesMacro.execute(JiraIssuesMacro.java:1276)
	at com.atlassian.confluence.extra.jira.executor.StreamableMacroFutureTask.renderValue(StreamableMacroFutureTask.java:86)
	at com.atlassian.confluence.extra.jira.services.DefaultAsyncJiraIssueBatchService$2.call(DefaultAsyncJiraIssueBatchService.java:212)
	at com.atlassian.confluence.extra.jira.services.DefaultAsyncJiraIssueBatchService$2.call(DefaultAsyncJiraIssueBatchService.java:201)
	at com.atlassian.sal.core.executor.ThreadLocalDelegateCallable.call(ThreadLocalDelegateCallable.java:38)
	at com.atlassian.confluence.vcache.VCacheRequestContextOperations$$Lambda$482/1202230221.perform(Unknown Source)
	at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContextInternal(VCacheRequestContextManager.java:87)
	at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContext(VCacheRequestContextManager.java:71)
	at com.atlassian.confluence.vcache.VCacheRequestContextOperations.lambda$withRequestContext$1(VCacheRequestContextOperations.java:59)
	at com.atlassian.confluence.vcache.VCacheRequestContextOperations$$Lambda$481/1654958417.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Error on line 38: An invalid XML character (Unicode: 0xf) was found in the CDATA section.
	at com.atlassian.confluence.extra.jira.JiraChannelResponseHandler.getChannelElement(JiraChannelResponseHandler.java:60)
	at com.atlassian.confluence.extra.jira.JiraIssuesManager$ByteStreamBasedSupplier.get(JiraIssuesManager.java:161)
	... 19 more

Notes

Note that the actual custom field data stored by JIRA/Zephyr does not need to be displayed in the macro for the error to occur. Only the Labels field is required, probably due to some mechanism in the plugin
On the JIRA/Zephyr side, the special character is stored in AO table "AO_7DEABF_CHANGE_ZJEITEM" rather than in "customfieldvalue" like standard custom fields. I'm not sure if this has any bearing to the issue but wanted to note that just in case
I cannot reproduce this with standard JIRA custom fields such as single or multi-line text fields

Attachments

Issue Links

relates to

CONFSERVER-45091 Jira custom field with special chars causes sorting in Jira issues macros to break

Long Term Backlog

CONFSERVER-54431 JIRA issues Macro error encoding UTF-8 to "Epic name" with special character

Long Term Backlog

CONFSERVER-54583 Jira Issue Filter doesn't work when unicode characters are used.

Long Term Backlog

mentioned in: Page Loading...; Page Loading...; Page Loading...

(1 mentioned in)

JIRA Issues Macro fails on Confluence when Issues have Special Characters