Why can't I enter a JIRA issue anymore?

[jason_s]

Atlassian – you seem to have stopped allowing people to enter JIRA issues in your public database. Boo. I can't enter any support tickets either because I'm just one person in my large company and I don't know the SEN and there seems to be no way to find out unless I pester the server admins.

Why is this?

[crf]

The reasons for this change are available in this public blog post:

http://blogs.atlassian.com/2016/07/improving-feedback/

The two biggest factors are really:

1. Submissions directly to jira.atlassian.com frequently went to the wrong project, were customer-specific so did not belong on jira.atlassian.com, were unreproducible, or were otherwise unsuitable to be worked on by development without additional information from the submitter.  Many of the projects also had no owner and therefore accumulated spam.  The blog post politely states that "many" of the issues were filed in the wrong place, but I would honestly say that this is an overly generous phrasing and that "nearly all" is closer to the truth. 
2. Invariably, customer-submitted issues required a back-and-forth with the submitter that involved gathering logs, system configuration data, and other sensitive customer information.  With jira.atlassian.com being a public system, it is not appropriate to have those conversations there, so the submitter pretty much always got sent to support.atlassian.com, anyway.  This game of ping-pong was frustrating and unhelpful for both sides, and it just means it took that much longer to get the problem fixed.

Clearly, requiring the SEN up front has its drawbacks.  On the other hand, if you don't have access to the SEN, then you very likely don't have access to the system logs or anything else that we are likely to need in order to be able to help you.  We almost always need to see the logs to understand what has happened, so your server admin really needs to be involved in this process, regardless.

[jason_s]

I get it, but I'm disappointed.

We almost always need to see the logs to understand what has happened, so your server admin really needs to be involved in this process, regardless.

For true support issues, yes, but for filing a bug report that can easily be reproduced on JIRA/Confluence/whatever, no, you don't.

I've filed a number of issues on JIRA over the years, including the following:

• https://jira.atlassian.com/browse/JRA-45342
• https://jira.atlassian.com/browse/JRA-44527
• https://jira.atlassian.com/browse/JRA-45578
• https://jira.atlassian.com/browse/JRA-60818
• https://jira.atlassian.com/browse/JRA-42310
• https://jira.atlassian.com/browse/JRA-42099

In each case I could actually show that the issue occurred in the Atlassian JIRA instance. So no, you don't need my server logs.

By requiring me to go get an SEN, you've added a barrier, and it lowers my motivation for filing these types of issues when I notice them.

---

I don't have a problem with using a different mechanism than JIRA (although now I can't demonstrate directly in the issue in question), but you should divide up support into "real support" and something that can be demonstrated on a publicly-accessible server, whether it's the Atlassian JIRA server or some sort of sandbox instance that you let people use for things like Confluence or Bitbucket.

[crf]

It sounds reasonable to me.  I get the impression that this is thought to be a relatively rare edge case, but I don't have visibility of all plans within Atlassian, so it's quite possible that there are other options for this that I don't know about.  I'll reach out to somebody that was more involved with the changes to make sure that they are aware of this feedback and see if there is a better answer we can give you for this.