We have an issue collector on which I've employed this workaround to require Name and Email (which we need to identify who is submitting the ticket).
When using the collector, an error is displayed saying something on the server side is misconfigured. When checking the issue collector from Jira, this is the error shown:
(IP and Email address removed)
We are currently on Jira 7.4.
I can't think of any changes we have made except that months ago I believe I used the web interface to upgrade Jira Software to the same version of Jira Core that's being used. I'm not even sure that's accurate, but literally the only thing I can think of.
Pretty embarrassing that you need to employ such a workaround just to get these fields to be required so someone doesn't submit a ticket without any contact information for us to use ...
UPDATE:
So, I've upgraded us to Jira 7.7 and the issue was still occurring.
I've remade the issue collector again, but this time I disabled the custom fields that I created and required (since the older collector code is now present in the installation, the fields were being duplicated).
This is still resulting in the same error. I have no idea what required field is missing or which one is too long because the error isn't specific enough. The only required field is the title of the issue now, yet it is still failing.
Maybe it's worth it to note that the actual ticket creation from within Jira has worked just fine through all of this.
I'm at an absolute loss here. The only thing I can think to try is to recreate our entire support project which I really do not want to do.
UPDATE 2:
Also, I will mention that the Catalina log is full of errors like this:
24-Jan-2018 15:30:31.678 WARNING [http-nio-8080-exec-52] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://jira.subdomain.domain.com/rest/activity-stream/1.0/preferences?_=1516826535713, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.
And Nginx is reporting stuff like this:
2018/01/24 15:34:02 [error] 5954#5954: OCSP_basic_verify() failed (SSL: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:Verify error:unable to get issuer certificate) while requesting certificate status, responder: ocsp2.globalsign.com
So maybe there is a certificate issue somewhere? I don't know which error message to trust ...
UPDATE 3:
I suppose I'm just yelling into the void here, but I've created an issue collector on a completely separate project that we use for internal tasks and it works without any issue whatsoever.
So I guess the lesson learned, just in case anyone finds this later, is absolutely do not use the workaround to require a Name and Email address linked above because it will inevitably break and then all issue collectors for that project are permanently broken and you will need to completely re-create the project in order to get them functioning again.
We were considering going all in with HipChat and Confluence integration but this has seriously left a bad taste in my mouth.
