In previous versions of JIRA, users without the JIRA Users Global Permission were not able to log in to JIRA, but if they belonged to a group that had Create Issue permission for a project, they could create issues via email if a JIRA email handler was set up, as documented here: https://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email
This is no longer supported in JIRA Software or JIRA Core.
In JIRA 7, a user must have access to at least one JIRA application (JIRA Software, JIRA Service Desk, or JIRA Core) in order to create issues, regardless of how the issue is created. This means that any user that is not able to log in to JIRA and create an issue via the Create Issue dialog will not be able to create issues via a JIRA email handler.
We have made this change to introduce more consistency in how licenses are enforced in JIRA.
Users without JIRA access can still create issues anonymously. You can set up anonymous issue creation as documented here. Please note that this may require you to delete users who do not have JIRA access so that JIRA considers them anonymous.
Additionally, we've introduced advanced support for helpdesk and support with JIRA Service Desk. Requests created via email in JIRA Service Desk support SLAs, queues, and more. JIRA Service Desk supports unlimited customers (people creating requests) starting at $10/month for 3 agents (JIRA Service Desk Cloud) or $10 for a 3 agent perpetual license (JIRA Service Desk Server). All JIRA users can view issues in a JIRA Service Desk project, so it is possible to just have a few Service Desk agents and a larger number of JIRA Software or JIRA Core users collaborating on the project.
Hi Team, The old system used to have this feature whereby I can automatically add the cc list to watch list but when I change it to Service Desk instead of Project, the cc watch list feature doesn't work anymore and cannot be configured. Ideally for a service desk to function correctly, I would want my partner to be notified via email when we reply to them automatically. However, with the new upgrade, this is something that cannot be done anymore.. I would need to manually add all the people in the email into the watch list if they didn't have "JIRA Software" access, this includes the reporter which is a very painful task to do. As such, the JIRA service desk functionality is no better than the current workaround solution that I'm using to make sure that I'm still getting my tickets. Thanks. Regards, Peiru
Hi @Pei Ru Lee, In JIRA Service Desk projects, you can add users to the Request Participants field. Requests participants receive email notifications when issues they're participating in are updated or commented on. If you connect your JIRA Service Desk project to an email channel, people added to the CC field when raising or commenting on requests will be automatically added as request participants. If you need further information about using the request participants field, or managing users across JIRA Service Desk and JIRA Software projects, please don't hesitate to contact our support team: https://support.atlassian.com Cheers, Sarah
I have actually followed the instruction recommended by @Dave_Meyer (link)[https://confluence.atlassian.com/adminjiraserver070/allowing-anonymous-access-to-your-project-749382794.html] but it is not the same as simply having a publicly available and accessible form for submitting issues, feedback, questions. Performing those settings will allow anyone to see the whole service desk contents. The way I see it, this JIRA service desk is now intended to be used only for internal customers (employees) of a company. This is regrettable.
After using the service desk component, I had come to realised that what we used to have is really a very good feature, as until today and several reports to the support team, they haven't fully solve all the issues I had with the SD. It seems to require a lot of complicated settings to make it work. Is there a guide somewhere that we can just read to make sure that we had setup everything correctly so that it would work? Also, for SD, non registered request doesn't seem to be getting logged anymore for some unknown reasons, do you know what happened? Thanks.
This basically make the issue collector useless. How can I log the user that created the issue using the issue collector, if they can't create issues? I use the issue collector as a feedback tool in my call center, with hundreds of agents. I cannot pay for licenses for all those agents that will never access JIRA.
please help me for below issue
We got below error message while doing test
"Found 330 unprocessed message(s) in the imaps folder. Only first 10 messages will be processed in test mode.
Cannot create issue due to invalid license: [Sorry, you can't create any issues right now, as you need to have access to
a JIRA application to be able to create issues. To gain application access you need to be a member of a group assigned to an application.]"
These kind of issues faced 4 times in last 2 months and after 1-2 days automatically 400 to 1000 tickets get created using from email
we are using Jira software from past Nov 2015with unlimited user licence(6500+ users) now, Error message shows licence problem even i enabled anonymous users for project under Browse and Create issue permission but difficult to predict what went wrong
please help me it is getting affected to many projects and users(120 projects + 3000 users in our company)
please let me know for any further input
Atlassian appears to have put a great deal of thought, time & effort into making JIRA a great platform for Agile development but the same can't be said about the SD component. Removing this functionality appears to be an indication that Atlassian is unaware of how Service Desk projects have been used by its customers. A more cynical point of view is it knows but doesn't care because some internal group decided that this was a tremendous revenue opportunity to effectively make every one of Atlassian's customer's customers an Atlassian customer.
When my company migrated to JIRA/Confluence at the beginning of the year, the transition to the SD component was challenging to say the least. The product we migrated from believed in the KISS approach and productivity with it was high. It was well understood by both our team and our customers. Send an email, create a case, converse via email, add a CC or a BCC, etc. No multi-step account registration workflow required. Support documentation could be made available without using up paid seats.
My team took a significant productivity hit while we worked on getting SD to serve our needs. Those needs very specifically involve supporting over 60 clients who use our software world-wide. Our customers are not technologists. There may be anywhere from a handful to over a hundred users of our products at any given client site. They just want to send an email with a support request and get help. Most of them prefer to handle these conversations completely via email and never log in to the SD portal except where forced to by JIRA's product design decisions. For Atlassian to assume that it will be known by us in advance which one of those hundreds of users at dozens of locations might submit a support request is just plain silly. To force them to pre-register on the off chance they might need help some day is not good customer service. So we now have a situation where our highly valued customers get no response to a support request and we have no way of knowing a request was even made! Until we get an angry phone call from that now unhappy customer.
I hope that you very quickly re-evaluate this decision to remove this core functionality from the SD product. If someone at Atlassian would like to discuss why such a significant change was made with apparent disregard for your user base or you would like more details on how we use the SD component, I'd be happy to get on the phone.
Same here, we are already a user of JIRA Software and Service Desk (hundreds of users, 50 SD licences).
This is a frustrating move that is obviously planned to push customers to SD that impacts your current paying customers. Someone in your company is trying to increase revenues and obviously do not understand your technology properly.... how can you have the right to create an issue from any email address perfectly fine and lose this right because you once sent an email to a Service Desk project? I don't see how it can make sense.
I am (was) a mostly perfectly happy customer. This is just a non sense can that can fortunately be fixed easily by adding the Create permission to SD customers for JIRA Projects with anonymous reporting activated. Just admit your mistake and fix it...
Please let me know if you don't plan on fixing this as we will start looking at alternative solutions. Be aware that it this obviously mean we might change our whole solution.
As a side note for other customers that have SD like me, I think you might be able to circumvent this by activating the SD module for the project but not assigning anyone as agents on it. (not tested).
I'm sorry you feel that way. If you want to give email create issue access back to a particular user you can give them application access. If you want this functionality for any user, JIRA Service Desk is a purpose built tool for this use case. As an existing JIRA user, you can try Service Desk for at least 30 days free and determine if there is value in it for your organisation. 3 agents is $10 per month for Cloud customers, and $10 per year for Server customers.
@Dave Meyer so there is functionality in the service desk used by atlassian that is not offered in the new JIRA 7, but it existed before that. Is that called "functionality degradation" ? I personally don't mind the new license (although it kind of sounds like Oracle technique), but when it comes to degradation of functionality for business purposes, that may backfire on you. I am about to finish a trial period of JIRA SD and next week I need to take a decision to go or not to go for your SD solution. I raised a ticket some time ago and eventually was closed with resolution "Existing bug" (SDS-8541). If that is the case, and you admit it is a bug, then as agile as you can be, please set a priority, timeframe and milestones to address this issue. It would be great if you could add the bug ID to this thread so that everybody interested can track the progress. Best regards,
@Dave Meyer : see JST-164952
I just put an end to a private support session with them. I spent the last weeks trying to explain how people were working. This is my last communication about this unless someone shows me clearly that you are listening to us. We're NOT TRYING NOT TO PAY SERVICE DESK LICENSES, we trying to explain that there's a bug in your design. Your licensing model changes DO make sense, there's just a small hiccup...
Here's the last answer, so everyone can get the explanation.
Allow me to get back at one of your latest statements:
I am using service desk for IT Helpdesk. When this user sends an email to my JIRA-SD project, he becomes a JIRA-SD Customer.
THE BUG is simply that he at this point looses the right he had just before which is to send an email to the JIRA Non-SD project. This cannot make sense, even from your business perspective. I sincerely think it's a collateral damage from the new user management feature you introduced in V7.
The ONLY right they should have is the same as the anonymous user. For non-SD projects, users with "Customer" account type should be recognized as anonymous users.
I'd like to contextualise it through this scenario: I have 1 Service Desk Project and 1 Software Project. For this Software project, if an anonymous user sends and e-mail to the address configured on mail handler, JIRA will create an issue to the Software project as the Default Reporter: anonyme. If this users sends another 2 tickets, both will be created correctly through the mail handler with the same default reported. The only blocker here would the "Create" Permission of the project and the mail handler set.
Now, here's what happens if this user sends an e-mail to the address configured in Service Desk Project: At first time (as a known behaviour of SD)this user will be created as a customer. The user base of JIRA will automatically refers to this user every time the same email address sends a new message. So now we have a Customer, which is not the same as a JIRA user. I agree with you, and he will lose the rights to create issues to the non SD project. This was explained by Dave at the answer I've shared with you, this is meant to be, designed by the Product Owners.
So here we have stated 3 important facts:
1 - User with no entry on JIRA's user base will be able to create tickets to non SD project thorough the mail handler:
Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter
2 - Anonymous users sending email requests to a SD Project will be registered as a Customer:
JIRA Service Desk public signup v.s. JIRA public signup
The two signup settings (the JIRA mode setting and the public signup in JIRA Service Desk) work independently. For example, if the JIRA mode is set to private and public signup is enabled for JIRA Service Desk, users cannot sign up for accounts to access JIRA, but they can sign up for accounts to access the Customer Portal of JIRA Service Desk. For more information about JIRA public signup, see Enabling Public Signup and CAPTCHA.
3 - As the PO is mentioning here the changes were made this way to "to introduce more consistency in how licenses are enforced in JIRA.". This decision was not made here at Support, definitely.
So, if you're considering the fact the Customer is not able to create new issues into non SD Projects a bug, feel free to open a request through the only available channel to report bugs : JAC. The only thing is that raising this kind of req might be closed as "won't fix" or similar, since it is running out of the scope of the new design. Just my opinion.
Let me know if you need anything else from our Support team.
I'm sorry for any inconvenience from our end.
Rodrigo Silva | Cloud
I will add my voice to the group here and express my tremendous frustration at this change. We spent half the weekend upgrading our system only to come in Monday morning and find that our help desk process was totally broken because our users could not create help desk tickets.
"But," Atlassian says, "we have this shiny new Service Desk product that will do what you want." That's great, but I've already tried it and it is way more complicated than what I need. The direct cost may be minimal, but the indirect costs in terms of setup, configuration (yet ANOTHER tool to learn), and maintenance are not worth it. One of the key benefits of using your products used to be ease of setup and use. No more, apparently.
So now we have to spend time coming up with a workaround solution using JIRA Enterprise Message Handler (an add-on we already own and like a lot) just so we can stay current with JIRA releases. Net result: no new $$ for Atlassian, time wasted for us, and a bunch of really annoyed JIRA customers. Nice work.
@Product Management, @System Administrator, @Customer Service:
Please forward this to who ever needs to be addressed for changing this or at least make an official statement.
It is 2017 and you still didn't manage to address this issue. That makes me sad and also my customers. It may give them a reason to leave the Atlassian stack as they experience similar tactics to drag customers into your ecosystem like g**gle, *pple & co already use. I hope you don't think this is really necessary. Isn't it enough that a company pays for their SD Agents and also let them propagate how nice the atlas-tools are? Revenue will be created a bit slower this way but all of us (providers and end-customers) have a good reason to stay with atlassian.
This is an absolutely ridiculous approach to running a business. We have always maintained our user basis.
The fact that you did not even notify your clients of such a drastic change is poor and unprofessional.
We now have to research new software whilst all tickets logged last week have been deleted.
Someone needs to take more responsibility. Due to this impact I guarantee you will lose a big customer base.
We are having the same problem! Currently we make use of Confluence very very widely across the company and also JIRA but only JIRA for IT related issues. I've not a problem with using anonymous for issue creation however I have made the changes and it's still not working!
This is because the people using Confluence are classed as users, I can't simply delete them from the system so they can send in IT requests and bugs!
This needs resolving and resolving very very quickly.
With this new "functionality" JIRA issue collector is useless.
Screen Shot 2015-11-12 at 09.12.30.png
In the Match Reporter selection area, there are 2 options as shown below.
Screen Shot 2015-11-13 at 09.42.14.png
This is the documentation suggested by @Dave Meyer
But if you choose "Attempt to match user session...." and the mail doesn't exist, how can I reply to the reporter?
You still need to invite the reporter to become a registered user and manually set the reporter in the ticket in order to be able to reply to the correct person.
Is there any other way?
As described in the JIRA Issue Collector documentation, you can turn off the "match reporter" option in your issue collectors if the reporters do not have access to a JIRA application. Then the issue collector will just use the default reporter you have set up. https://confluence.atlassian.com/jira/using-the-issue-collector-288657654.html
The wait is over... Portfolio for Jira Server and Data Center 3.0 is now officially here! Platform releases offer Atlassian an opportunity to shift our strategy, make bold predictions about t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs