-
Bug
-
Resolution: Fixed
-
Medium
-
7.13.9, 7.19.1, 7.19.3, 7.19.4, 7.19.6, 7.19.7
-
8
-
Severity 2 - Major
-
64
-
The fix for this bug will be backported to our current Long Term Support releases if it passes our risk assessment.
We recognise the impact of this bug and plan to backport the fix to our Long Term Support releases. Once the exact fix version is known we will update this ticket. Not all code changes are suitable to be backported and this may still be rejected during our review process.
Environment
- Confluence 7.13.9
- Jira 8.20
Steps to Reproduce
- Create a Confluence page.
- Insert the Jira Issues macro.
- Insert a JQL filter and include only specific custom fields you require.
- Save the Confluence page.
- Reload the page.
- Review the Jira access log regarding the request called.
Expected Behavior
Only specific custom fields as defined in the Jira issues macro will be searched. field=allcustom parameter should be removed.
Actual Behavior
All custom fields are being searched through and it causes the search to be extremely slow especially with instances comprised of large amount of custom fields. field=allcustom is apparent in the request URL e.g.
"GET /sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?tempMax=20&returnMax=true&jqlQuery=key+%3D+PROJ-1+&field=summary&field=type&field=created&field=updated&field=allcustom&field=duedate&field=assignee&field=reporter&field=priority&field=status&field=resolution&field=customfield_10200&field=link&field=type&xoauth_requestor_id=xxxxxx HTTP/1.1"
Workaround
There is no known workaround. Once a workaround is found, it will be added in this section
Note:
The issue doesn't seem to happen on Confluence 7.13.8
[CONFSERVER-80386] JIRA Issues Macro fetching unnecessary fields from JIRA
We also have a high number of custom fields and this has greatly affected Jira. Early awaiting a backport to 7.19 LTS.
We've tried a workaround similar to above but rewriting the parameters via proxy then results in an oauth invalid signature error. Seems there is no workaround besides switching to use some other Jira issues macro entirely.
https://getsupport.atlassian.com/browse/PS-128687 - 7.19.7 too
Hi! We are affected by this bug after our upgrade from 7.13.7 to 7.19.6 and it is affecting high visibility pages. We are not able to upgrade to any non-LTS versions, any information about when a backported fix will be released to LTS 7.19 would be greatly appreciated. Thank you!
Will this also be backported to the latest LTS - and if yes until when?
A fix for this issue is available in Confluence Server and Data Center 8.1.0.
Upgrade now or check out the Release Notes to see what other issues are resolved.
I will note that we've seen this regression bug continue to affect all Confluence 7.13.x versions, including 7.13.8.
Same regression experimented after a Confluence migration from 7.14.2 to 7.19.2 with Jira 8.20.11.
Possible Workaround ... Rewriting Query String of URL on Jira side, in order to remove unexpected parameter field=allcustom:
RewriteCond %{QUERY_STRING} ^(.*)&?field=allcustom&?(.*)$ [NC]
RewriteRule ^/?(.*)$ /$1?%1%2 [R=301,NE]
It works ..
I tried to apply ot only for Confluence with
RewriteCond expr "%{HTTP_REFERER} -strmatch '*://<hostConfluence>/*'"
RewriteCond %{QUERY_STRING} ^(.*)&?field=allcustom&?(.*)$ [NC]
RewriteRule ^/?(.*)$ /$1?%1%2 [R=301,NE]
where you will replace <hostConfluence> by your relevant Confluence Base URL.
But it fails for the moment ...
Always looking for correct syntax.
Vincent
A fix for this issue is available in Confluence Server and Data Center 7.19.14.
Upgrade now or check out the Release Notes to see what other issues are resolved.