Unable to create JIRA issues via Confluence because the Assignee field is shown as required, but broken
This was tested in Confluence 5.5.2 with an application link to JIRA 6.2.3
When adding a JIRA issue in Confluence (via the Jira Issues Macro), the Assignee field shows up and is marked as required. However, the resulting user picker does not load, and therefore the entire functionality breaks as the user is not able to create the issue.
There is initially nothing showing up in the Confluence logs. However when one attempts to type anything into the Assignee's user search field, the following will appears in the
2014-06-18 16:08:05,944 WARN [http-bio-5552-exec-15] [internal.integration.jira.DefaultJiraService] communicateWithJira Problem communicating with JIRA -- referer: http://localhost:5552/display/ABC/abc+Home | url: /rest/jira-integration/latest/fields/autocomplete | userName: admin com.atlassian.sal.api.net.ResponseStatusException: Unexpected response received. Status code: 404 at com.atlassian.applinks.core.auth.ApplicationLinksStringReturningResponseHandler.handle(ApplicationLinksStringReturningResponseHandler.java:19) at com.atlassian.applinks.core.auth.ApplicationLinksStringReturningResponseHandler.handle(ApplicationLinksStringReturningResponseHandler.java:13) at com.atlassian.applinks.core.auth.oauth.OAuthApplinksReturningResponseHandler.handle(OAuthApplinksReturningResponseHandler.java:51) at com.atlassian.plugins.rest.module.jersey.JerseyRequest$2.handle(JerseyRequest.java:166) at com.atlassian.sal.core.net.HttpClientRequest.executeAndReturn(HttpClientRequest.java:351) at com.atlassian.plugins.rest.module.jersey.JerseyRequest.executeAndReturn(JerseyRequest.java:161) at com.atlassian.applinks.core.auth.ApplicationLinkRequestAdaptor.executeAndReturn(ApplicationLinkRequestAdaptor.java:78) at com.atlassian.applinks.core.auth.oauth.OAuthRequest.executeAndReturn(OAuthRequest.java:55) at com.atlassian.applinks.core.auth.AbstractApplicationLinkRequest.execute(AbstractApplicationLinkRequest.java:159) at com.atlassian.internal.integration.jira.DefaultJiraService.getAutoCompleteItems(DefaultJiraService.java:579) at com.atlassian.internal.integration.jira.DefaultJiraService$2.apply(DefaultJiraService.java:258) at com.atlassian.internal.integration.jira.DefaultJiraService$2.apply(DefaultJiraService.java:254) at com.atlassian.internal.integration.jira.DefaultJiraService.communicateWithJira(DefaultJiraService.java:641) at com.atlassian.internal.integration.jira.DefaultJiraService.getAutoCompleteItems(DefaultJiraService.java:254) at com.atlassian.internal.integration.jira.rest.JiraFieldsResource.getAutoCompleteData(JiraFieldsResource.java:44) ...
Though the problem is manifested in Confluence, the problem is actually based in JIRA. As such, you will require access to the JIRA Administration console to diagnose this issue.
- Go to JIRA Admin > Projects
- Click on the relevant project (that is, the same project you're seeing the Assignee field in Confluence)
- Look for the following two settings. Both of the below must be true for this Knowledge Base article to apply:
- Under Roles, the Default Assignee is "Unassigned"
- Under Fields, click on your Field Configuration. The Assignee field is marked as "Required" next to its field name
The JIRA system field "Assignee" should never be marked Required, and therefore should never appear in Confluence's JIRA Issues Macro. There is simply no such option for this field to be toggled as Required inside of JIRA. However, through some unknown cause, this field can be marked as Required, and therefore will cause it to appear in Confluence when creating a new issue.
- Click "Hide" for the Assignee field. This un-flags the field as Required.
- Click "Show" to un-hide the Assignee field, which is now no longer required. This also means in Confluence's JIRA Issues Macro, the field will no longer show up during issue creation.
Please note that this workaround takes advantage of the fact that JIRA automatically un-flags fields (any field) as Required when they are hidden. If the product changes such that this is no longer true in the future (e.g. if JIRA starts to "remember" whether fields are required or not despite shown/hidden status) then this workaround will no longer apply.