Are there any plans to fix this? To at least allow any Jira user to edit issues? We are likely having to abandon Jira Service Desk due to these restrictions. It makes JSD almost impossible to use for internal JSD installations.

Atlassian, do you realise what this means? By holding on to this restriction (you must be an agent) you force project admins to allow collaborators as agents. The project admin then has to implement conditions into every workflow step.

A huge downside as well is that these collaborators (now agents) can comment externally. This is a problem for us considering we can't put the internal comment first. (https://jira.atlassian.com/browse/JSDSERVER-1733)

Yep, cannot agree more about "Jira Service Desk should not restrict to only agents normal jira access to edit, reopen or perform transitions. All jira-users should be assignable owners. Instead, the project permission scheme should be honoured."

Hi Kelly,

We recently shipped the functionality in Cloud that allows customers to approve requests: https://confluence.atlassian.com/servicedeskcloud/setting-up-approvals-816880004.html.

We are also working on JSD-40 actively at the moment. Stay tuned!

Cheers,
Lingbo

I agree with other's sentiment. The fact that the service desk restrictions disable the ability for other workflows within the same project to function renders the Service Desk useless. The support advise me to create separate projects for Service Desk and our other workflows but that makes it unsustainable. Our used case is that Service Desk is used for a product but other workflows require our customers to interact with us by the mean of workflows such as but not limited to: software development, governance, risk management.

Please remove these restrictions or ensure that they only apply to the service desk workflow. This is very important.

We are trying to implement an new user request form in the service desk and if you can edit fields on create why not after that?
Please implement this change or allow:
https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.actions.jsd-actions/server/overview to be purchased for the cloud version

This restriction renders the whole Service Desk feature useless for us.
Our agents need to be able to assign issues to developers so they can work on the issue/solve the problem. Service Desk overwriting our permission schemes is simply absurd and counterintuitive (not really expected behavior => I define a permission A and SD says "Oh no! No way!"). Our Devs don't need access to Queues, SLA/Measurements/Reports and the whole SD stuff - but they need to be able to execute issue transitions and edit issues at least!)
We've been using SD for two years now and are evaluating now other possibilities without JIRA Service Desk.

In plugin Actions for JSD there is option for customer to execute some actions on customer portal. They can Edit/Assign issue and execute transitions.
Here you can find how to do it:
https://intenso.atlassian.net/wiki/display/SPFJSD/Workflow%20Actions
https://intenso.atlassian.net/wiki/display/SPFJSD/Edit+issue+in+Customer+Portal

I hope I've helped you.

@ Adrian Hass: I asked exactly the same question @ JIRA 3.0 F.A.Q. - unfortunately nothing is going to change:
Source: https://answers.atlassian.com/questions/31655161/how-about-service-desk-licenses

BUMP! After all this rework for JIRA 7.0 and SD3.0 I was expecting a change (at least the assignability!) on that... Seems like nothing has been done?

We have the same problem at our site.
Our developers should not be able to make external comments, hence they should be collaboraters and not agents.
But we have to be able to assign the Tickets to them (Having the agents make Tickets and assing those, just so they can properly assing work on a ServiceDesk Ticket to a devloper workes against the reason JIRA is used with us in the first place. We want to cut down on Ticketvolume not increase it! In addition, tracking the progress on all those Tickets is proving to be a nightmare)
So, for assigments sake we have to make our developers into agents which brings us back to the comment problem...

I really hope, that this issue will be adressed soon. Right now, SD is creating a lot of unnecessary work for us....

@JSD: When will there be an update on this issue?

I was experienced hard times to explain THAT ^^^ to my sups !
I have some Project Managers with experience in JIRA but not in JSD ! It was very hard to show them that JSD is kinda "bitch" when you have to play with users/agents rights...
Thank you @Jacob for the ticket.

Any workaround available for this issue?

Has there been any movement or updates on this?

I've voted.
I honestly do not understand the behavior of this plugin. Who you may find it useful?

Nothing more to say. I've voted and now I'm watching this issue.
Big blocker for us, basically makes Service Desk (which we paid for) useless, as I had to turn it off.

I think this relates to JSD-1517, basically changing the Service Desk so that Customers can work on issues from within the normal Jira interface if they have a license already. This would allow both the Portal and the normal Jira interface to be used as appropriate.

I would agree, I want to have agents who manage the tickets and the relationship with my client but the agent needs to be able to assign the ticket to a developer, the developer then needs to log work and assign it back to the agent for checking.

I have built the workflow for this and it works really well, however I have to make each developer an agent so they can do anything with the tickets.

Can someone confirm that collaborators cannot even have tickets assigned to them? We are possibly having to move to Service Desk 2.x from 1.x and this will completely mess us around - it's less important that the collaborators edit a ticket but if they cannot even be assigned tickets then what is the point of them? Offering them as "you can have as many as you like" when they cannot be used in any useful way makes no sense. Please please escalate this and change the restrictions - this makes a joke of Service Desk 2.x and its support model.

I agree, I know they're trying to make money but collaborators basically have no permissions they might as well be customers.
The ability as a collaborator to only view and add internal comments with no ability to edit anything on the issue is ridiculous.
An agent should be the front end between customer/platform where an agent controls what is said between customer and support team but there shouldn't be limitations on a collaborator for assigning/editing a ticket. An agent should be allowed to "collaborate" with other users, meaning work jointly on completing a task. I mean how will a collaborator even know to work on a ticket if they can never be assigned it or be notified?

I could not agree more. The promoted principle by Atlassian of having a separate non-service desk project for the workflow of the tickets assigned to the developers is nonsense in respect of being able to manage the speed of resolution. What is the point of applying an SLA to an "agent" if that agent then has to essentially sub-contract to the development team but cannot apply any SLAs for that part of the workflow. The agent becomes powerless to ensure that they keep to their own SLA due to the dependency on development (or technical analysis etc. at ITIL levels 2 or 3) without the ability to monitor KPIs/SLAs for the dependency.

Absolutely Agree. The licensing model as is does not make any sense and assumes support desk users are also capable of resolving technical issues. This is typically not the case and the support desk personnel simple triage issues to the appropriate development team. These developers need to therefore work on the issues in JIRA. To pay an additional license for every developer in every development team just in case a support ticket is raised that a specific developer needs to fix is not cost effective and does not support the adoption of the product. We are currently having to create duplicate tickets and then communicate via comments to the support desk once an issue is complete - this is cumbersome, prone to errors and miscommunication and makes no sense when JIRA functionality is designed for this very purpose.

Atlassian - please review the pricing model to support adoption of the Service Desk. Suggest providing a Service Desk fee based on the number of Agents (i.e. existing pricing $10 for 3 Agents etc.) and then a fixed premium for the total number of JIRA users (e.g. ~50 JIRA users $50 per month).

Many Thanks
Alistair

I strongly agree.

Our use case is that our Collaborators often need to edit an issue (for example, tagging it as "ready to push to QA server"). We need our Collaborators, who are all licensed JIRA-users, to be able to work with issues in the normal JIRA way. All JIRA-users should be able to edit issues or be an assignable user. The project permissions scheme should be honored.

As licensed JIRA-users, my collaborators are not Agents. Because they are not Agents, I understand they will not be able to see or manage SLAs, queues, or see the Client Portal. But JIRA-users should still be able to use JIRA.

This one is nagging more people. See also;
https://jira.atlassian.com/browse/JSD-931
https://jira.atlassian.com/browse/JSD-861
https://jira.atlassian.com/browse/JSD-884

And the discussion thread on https://confluence.atlassian.com/display/AOD/Managing+collaborators

If you agree - please contribute/vote up!

It seems that Atlassian is leaving the path towards ''Dream big, work smart, deliver fast'' and starts introducing silo's itself. A pity, to use an undertatement, 'cause it limits the potential of Servicedesk - even to the point that the added value becomes questionable.

I also agree that this is ridiculous. The comment on Answers from Carl says it best.

https://answers.atlassian.com/questions/9372106/assign-issue-to-non-agent

What could possibly be the use case for this type of functionality? The user story would more likely be, "as an agent, i want to triage tickets to a large number of potential developers". why do all those developers need agent access? Also, this is really just going to make me create a workaround through a generic mail handler to create tickets in a non-service desk project and then design the appropriate dashboards. You are not doing anything by prohibiting this functionality other than making my job as an admin more difficult, and making SD largely pointless as an ITSM tool.

Is your goal to improve the Jira + Service desk functionality or just drive SD licenses? It seems counter intuitive.

Guys,

Assigning the transition permission only to an agent is a backdoor for increasing the costs for the SD licence, quite contrary to your blogpost http://blogs.atlassian.com/2014/09/introducing-jira-service-desk-2-0/

With this setup we need to assign the agentrole to every developer. We are certainly interested in JIRA Servicedesk, but this could be such a drawback that we have to review the business case.

Please adress this.

This is killing for our environment, we want to be able to assign tickets to our developers. Now we have to duplicate all tickets, which is madness.

There should be an option to assign to developers, even though there is no SLA information; that is not important for developers.

In 1.0, we were able to expose issue types that would directly hit Kanban/Scrum boards. One example for us was project ideas (we created a custom issue type called 'Initiative')...anyone from our company could submit an Initiative that automatically went into the 'IDEA' column on our prioritization board for review, deferrment or planning. Nobody every had to touch a queue...it just went to where it would be worked on/reviewed automatically. With 2.0, we now have to have a separate Service Desk, in which one or more agents have to go and 'clone out' the initiative requests that come through back into the JIRA project where we have our Initiative prioritization board. Adding a middle-man between the customer and individuals who will work the requests seems like a backwards step. At a minimum, enabling folks in a JIRA project to be able to edit issues that come in through their Service Desk would resolve our main beef with 1.0.

It's important this issue, because normally the rol developer must do assign issues, transtion workflow, edit worklow and now with the new JSD licensing we must assign to the developers a service agent desk license.

Regards.