JIRA Service Desk Overrides JIRA's edit permission, you need to have an Agent License and a member of the Service desk Team in order to edit issues.
If you use the permission helper, it will show you the conditions needed to edit the issues.
I'm having the same problem
I did edit de global and project permissions, so my customers would edit their own comments and delete their own attachtments, but it doesnt work.
So there is no way customers can edit comments if they dont have agent license o the global permission to edit?
I also think it's totally ridicolous that you need to let a customer become agent just to simply edit their description. I also would like to have that feature ... the customer should be allowed to correct and change the request in specific states.
I'm currently having a trial license of Jira service desk, but more and more get the feeling it's too inflexible (like also you can not add more (custom) fields to show in the portal), so thinking about to move on to another helpdesk system..
i tried adding service desk customers role to the edit issues permissions and it didn't work, in fact JIRA gave me an alert stating there was an error in the permissions. Does anyone have a step by step to enable service desk customers to be able to edit their own issues? I don't mind if they can edit any issue in that particular portal even.
this is pretty strange behaviour to override edit permission,
since some cases need this.
E.G.: we're having account request forms with checkboxes, dropdowns, etc.
And sometimes things need to be changed afterwards, by the requester. ;)
Could this be added please. Otherwise this feature lagg will make the product static as hell and not as proclaimed agile.
+1 for allowing users to edit their own support tickets. It's amazing we're even having to discuss it as being an option. This is the only support ticket system I've ever used that does not allow this.
We can acquire information through the form at point of submission, but things can change. Priority can change. The client can have an additional conversation with the customer and acquire more information that needs to be added. There is too much churn back and forth for Developers to be responsible for updating a client's support ticket for them.
+1 from here as well. Maybe one day such basics will be available, hopefully before nobody uses Jira SD anymore? 🤔
Of course I understand that Jira want's to let some of these options for their partners and market place vendors to do their share of business. Unfortunately such basics are not yet(?) available even from add on side so you can't get such basics even when paying for them some extra? This is even more ridiculous from Customer point of view. 😔
After several years customers have being complaining about lacking such basics and still we're in the square 1, how it's even possible? 🤷♂️
You're right Taulia, the customers can't edit issues.
For more information about permissions between Agents, Customers and Collaborators, I'd advice you to take a look on the following link:
This makes NO sense. Our customers need to be able to change the priority after creation. They need to be able to set a due date after creation, they need to be able to set a screen field on transition.
While I understand you want to have as many users paying for JIRA and agent subscriptions, it is ridiculous to restrict the simple ability to edit fields after the issue is created. We waste so much time editing issues via customer comments.
I also see this is common in the Atlassian feedback systems and yet there is never any Atlassian comment or action.
So frustrating that we are going to probably move from the Atlassian service. We have over a hundred staff on Confluence, Jira and Service Desk, yet the nit picking in Service Desk is too much of a headache to outweigh the integration benefits.
Question @Marc Turner , why would you not set the priority and due date when the ticket is created?
Additionally, We have Service-Now and we cannot change the original data in the submission ticket. I think this is a best practice for ITSM is not to allow the original request to change.
you can also look at products such as Backbone that will allow you to sync issues between a service desk project and standard JIRA software project.
I haven't tried this but the workflow could be modified to show an "update" transition to the client and add a screen to that transition with the fields to be updated or just modify an existing transition e.g. escalate. I know this works for the Resolved transition when setting the resolution. If this works for editing initial fields values, it would need to be added to each applicable workflow status and by using JSU restricting the Client to return to the previous status. Has anyone tried this?
Jeffrey, we are using the My Requests Extension for Jira Service Desk to show the priority in our case the SLA priority.
The problem we've been facing internally is that customers are able to clone previous issues, but then not edit the information in the now cloned ticket. If Atlassian is going to stand behind this completely poorly thought out restriction, please add the restriction of not letting customers clone tickets.
Customers often come into a service desk and start developing a ticket. Sometimes its necessary to multitask and do research or have to come back to a ticket later with more information. This situation is where the customer needs a draft status. Not having this capability is very limiting.
Hello there Cloud Community members! Today, we’re thrilled to announce Jira Service Management, the next generation of Jira Service Desk. Jira Service Management touts advancements in IT service ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events