Issue Collector with Required Name and Email Fields Failing

[Colin MacCreery]

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.

[Benjamin Dains]

Email handlers are pretty interesting in Jira from the experience that I have had with them. Leave them alone and very basic for the most part. There isn't a whole lot that you can do with them at the moment.

I only use the email handler to dump the email body into a issue and then I run automation on the issue based on what is passed into Jira.

The HipChat and Confluence integration really is good, and if you have the ability to create issues through Confluence into Jira, it's a much better model for what you're looking for vs using the email handler.

Honestly the email handler functionality you want would be included with Jira Service Desk.

[Colin MacCreery]

Yeah, I just didn't want to have a full-blown Service Desk instance just to get tickets from staff (which we seldom get). Usually, we are creating the tickets ourselves from an email or personal contact.

However, I will update that even after the creation of a *new* project, which was working for a while, the collector eventually failed again in the same way. I'm at an absolute loss and I feel my only option is to re-install the entire software on a new VM.

It really seems like due to the Catalina log messages that there is some weird error occurring here, but I just cannot track it down.

[Benjamin Dains]

@Colin MacCreery agreed, I didn't want to have to get Service Desk just to be able to pull in fields as well. I think Atlassian could make some very happy customers if they built out their email handler to accept / reject incoming field data.

--

Side note: I noticed you said you had the software installed on a VM, are you working with the server / data center implementation or Jira Cloud?

[Colin MacCreery]

We are self-hosting this instance.