We get a error notification in the system default email handler:
You do not have permission to create internal comments on this issue
Let me explain how this error occurs.
We have a customer, that sends in a email request to our servicedesk. Ticket is created, and the mail adres of our customer is added as reporter. Customer recieves a notification of the created ticket.
The notification is send to firstname.lastname@example.org
Now the user is not in the office, and has a shared mailbox with user2. User2 opens the mail send from our servicedesk, and replies to our servicedesk. the sender email adres is not user1 but email@example.com and the error appears in the email handler.
If user1 then replys to the same email jira has send, the mail is succesfully processed. We dont have watchers, or shared tickets.
We have a lot of customers who manages a lot of mailboxes, so the sender email adres my vary. We want that if there is a reply to a ticket, no matter witch email adres is used, that the comment is proccessed. Not only from the reporter.
How can we make this work?
Jira Service Desk is still very much a permissions based platform. The way Service Desk is checking accounts when it comes to email messages is looking specifically at that email address of the sender. If that email address sending the reply is not associated with the account of the reporter, Assignee, or Requested Participants, then there is no permission to comment on the issue. That is by design. Just because a user forwards a service desk notification to another email address is not sufficient to grant that other user access to that specific request.
I would recommend taking a closer look at Choose who customers can share requests with. This document explains that in Service Desk you can configure the project to limit who users can share their requests with. By default this is pretty limited, so you will likely need to adjust this a bit to ensure that other users can be added to this request first.
Once that is done, then the next steps are to encourage the users that create these issues in service desk to also include the email addresses of the other users that might need to respond to this issue.
If the user1 knows that other users are going to need to be aware of this issue, when they send the first email, they can easily add in the To or CC field of their email the other recipients in addition to the service desk mailbox. In Jira Service Desk, this has the effect of adding all the other recipients to the requested participants field (provided they already have an account in Service Desk). That way the other users could then reply to this issue from their address instead.
The other alternative is that after the issue is created in Service Desk, the user could then share the issue via the customer portal, but this is dependent upon the project settings as I noted in the documentation link I posted previously.
This way, the other users would have permissions to comment on this issue. Please let me know if you have any questions or concerns about these steps.
Thank you for your quick reply. I have read the article you gave me, and verified the settings. The settings for my share request are: anyone based on email. So in my opinion this setting is good.
Next step was to create the customers in our servicedesk, and checked if they had access to the portal. We have now user1 and user2 correct in Jira SD.
But still if user2 replys to our servicedesk, and want to comment on a existing ticket it fails. The same error appears.
Are there other possibility's so that we can make this work .We have a lot of different customers that are not so good with computers, so if i have to explain them that only the reporter can reply, im guessing that they all gonna call it in instead of using the servicedesk.
The next step is to add the other accounts to that specific service desk issue under the requested participants field.
This can be done on the issue itself (either by the Agent in the main Jira site by editing that field, or by the Customer in the customer portal using the "Share" option for that request), OR if the reporter is working out of their inbox, the reporter can add in the CC field of a reply email of that issue the other email addresses to send this message to. Without this step, the other individual accounts still don't have permissions to post comments to that specific issue.
There is no way around the need to share this issue with the other users first. The way you can do that varies as mentioned above. In addition to those methods, you could also setup the service desk instance to use the Organizations feature. With this feature you can help group together customers from the same team/company. The benefit here is that if customers are creating requests in the customer portal, they can then see the option to automatically share their request with other members of their organization. This is just another way to give those users access to the issue.
We have already users grouped in organisation. We are a IT service company for customers who does not have there own IT department.
Our customers ( more than 1500 users devided in 300 groups ) wont take the time to log on the customer portal.
All our users forward the mail trough each other, and then back to the sd. If we cannot get Jira to accept the mail, even make a new ticket im afraid we need to migrate to an other system.
Now customers are calling, and saying, if fwd the message to you, but you didnt respond. Log file says the same error.
There also going to cc everything to my business email, and that was the reason we introduced Jira.
Is there a official or unofficial way, that jira accepts all mail, regarding reporter ?
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot