Hi there, 

Is there any update?

Hi there, 

Is there any update?

Hi there, 

Is there any update?

Hi there, 

Is there any update?

Hi there, 

Is there any update?

Hi there, 

Is there any update?

Hi there, 

Is there any update?

In total agreement with Curtis.  The ITIL ready Service Desk includes Change workflow.  But you can't allow change managers (not service desk agents) the ability to edit and transition (i.e. approve) directly from the Jira issue.  This is a huge setback in pushing forward our change management process.

Currently we have multiple projects where change requests are created.  We would love to drive everything through our Service Desk, but the permissions mess isn't allowing that.  It's funny, the permissions scheme should allow for letting certain groups transition, edit, etc. without communicating with customers (i.e. the service desk agent permission in the scheme).  But it just doesn't work.

This is extremely frustrating!

Completely agree with above comments. Until this is fixed I am recommending our other internal teams who might buy JSD to not buy it. JSD only cause more problems in most cases I have seen. May be if your team is dealing with few requests a day then they can manually clone the issues to be worked on by internal teams. If you constantly in need of your internal teams working on customer requests internally then JSD is not for you. 

This problem feels contrived and unnecessary by JSD's weird licensing model. I know you need to keep JSD profitable for users that just buy agent seats, but just keep it simple Atlassian: if a customer paid for a Software/Core license, they paid for the right to edit, assign tickets. Don't take that away from them when they are actually giving you more $$$. That's a poor way to treat customers. The value add in JSD is the portal management, SLAs, queues, automation, canned responses. By all means, keep those to agents, but do not strip away basic Jira abilities people already paid for.

We are seeing this as a problem for using JSD for our Change Management workflow to facilitate the approval  and history of changes to our production environments. We have many developers, who need to submit change requests to our Operations. These change requests though, often can change, so if the developers can't edit the change once submitted, this means our operations or Managers who have JSD licenses must make the necessary edits.

If the developers with the Software licenses though could edit these change issue types, then it would alleviate a lot of the load on the others to make it for them.

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)

We need our collaborators to be able to transition and edit issues but don't want them to be able to make customer facing comments. There is no option for this. Either they are assigned Browse Project permission where they cant add customer comments but also cannot transition / edit issues or add them as a SD Agent meaning they can transition/edit but can also add customer comments. This limits collaborators and really they are not collaborating at all, just commenting.

Same problem. Applied Service Desk to our Internal IT Help desk for just one issue type, but then realized that made all the other issue types that rely on approvers from other departments and steps from the development team unusable. So have had to strip away the one issue type where only IT is required to move the issues around over to Help Desk. Or consider adding in a lot more agents just so they can "approve" a change request.

Any idea if Atlassian thinks about giving back some permissions to the collaborators?

Is there an official statement from Atlassian regading that topic?

Our whole Service Desk has been built around the "old" license scheme - it seems to became useless in an instant after applying the new license. This is really a shame!

Totally agree with Amanda and Jon.

Agree with Amanda - this limitation of roles in terms of Agents and Collaborators has a massive impact on our future use of JIRA, even with the more modular system Atlassian have provided in JIRA 7. Totally understand that Service Desk as a standalone tool (separate to JIRA) is a less costly offering than other tools of its ilk, but the permissioning around having to have Agent licences to do anything on a ticket or be assigned one is flawed. The term collaborator is used as someone who collaborates - ie helps on the issue to provide a resolution, thus should be able to have tickets assigned to them and perform basic functions like move it on a step in a workflow or edit and add data. Otherwise, even by adding a comment, there is NO way to record their help.

Collaborators need to be able to transition issues to actually be collaborative. In our pilot build out we used Collaborators and workflow transition steps to handle necessary functions before passing back to the agents, and now without this functionality we are unable to proceed with Service Desk

I am also astounded by this backwards move. The beauty of Atlassian products in the past has been complete control admins have over configuration of these systems.

This is a major step back in my implementation and while we love having the ability for non-license count JSD users, it came to us at a great cost of completely breaking our internal support structure.

Not being able to edit fields and manage watchers is a major step back, requiring me to use agent license seats for reporters.

I am actually stunned that JSD not only takes away permission control but also renders all other role permissions useless. Fact is that only agents can work with issues from a JSD enabled project. None else can edit, transition or assign issues. The other JSD roles are useless. A collaborator cannot collaborate. The role should be called "commenter" because that is all they can do in the end.
We have thousands of users in our environment that need to work on issues. They need to edit them, assign them and transition them so the work gets done. They are not agents in the JSD sense, they are workers, real collaborators if you will. And what I can read from the other comments here, that is how the world works out there.
After we enabled JSD for the first project it took 15 minutes until we disabled it again because nothing worked anymore. Production got to a halt. I am very disappointed. An absolute No-go for this product.
I have no idea how this permission concept made it into the product. It does not reflect how service teams work, definitely not in large environments. The only reason that comes to my mind to only allow agents to work on issues is that Atlassian wants to make money out of this, a lot of money. $45000 for more than 100 agents? Really?
Please allow the JIRA permission schemes to work in JSD enabled projects. Give control to your customers about what the JSD roles can or cannot do in a project!

I agree!! Collaborators must interact with issues of SD. In our model we have the SD team (agents) for the first analisys of ticket but when an issue go to "1 level support" we need other persons (programmers) that analyze and work on it.
I'm not able to assign the ticket to programmers ("collaborators") and this is a limit! Also, programmers are not able to load log work for example and it's a second limit.

Strongly agree!!

We're currently using Service Desk v1 (JIRA user based), but we're thinking about switching to service desk v2 (Agent-based). We're in the process of 30 day free trial and noticed a lot of issues with permissions. We'd like to allow collaborators to edit or transition the issues. In our case, we have different stages of triaging the issue. When issue first gets created, it gets transitioned from "Open" to "Level 1 Support". After Level 1 is done with their work, the ticket gets transitioned to "Level 2 Support", then to "Engineering". After "Engineering" is done with their work, they have to transition the issue back "Level 1 Support" for them to contact customers to deliver the fix,etc.
Without this, we'd rather stay with the old version and things work just fine. Please let us know if this is possible. We need to make this decision before the 30 day free trial expires!

I absolutely agree. Having the restriction on 100 agents is an obstacle for us to fully deploy Service Desk in our workplace. Due to the sheer volume of collaborators and staff we have involved in supporting a large number of tools and applications, this is a must, if we are going to push it as our primary service management system.

Totally agree - we are currently working with Portal v1.x and the benefits of us growing our use of the Portal to take over a lot of archaic functions in our company is why I'm pushing for more use of JIRA and Portal - however the v2.x issue with Agents and Collaborators is causing huge pushback re costings. It makes no sense that a collaborator on a call from the Portal cannot do simple JIRA functions - Agents just have greater access, ok, but please please please change the model to allow collaborators to action workflow elements, have tickets assigned to them etc ... otherwise you've created completely useless function in JIRA. This is causing negative feedback on what has been, to date, a great tool for our business - the benefits it WAS bringing meant we were bringing more and more of our day-to-day roles into the Atlassian world ... but this is a stopping point for us.
Everyone is screaming for this - please listen!

this is a common use case, and it is quite surprising that it was not considered as 'necessary' for the standard Service Desk usage model.

By mis-assuming that either, everyone in a development shop will happily just purchase agents license for the 'techies' (the cost of which is prohibitive, since we are talking an entire development staff: developers, testers, analysts, etc.) or that the bottle neck of having two separate projects that now must have issues linked and kept in sync by the help desk agents - the service desk offering provides only very limited benefits until this can be resolved.
It may be that Collaborators would require some type of licensing beyond the base JIRA license, to account for the added service desk/development integrated functionality.
But requiring that anyone needing to act on a service desk ticket to have an agent license (even if only employing base JIRA features) is really misconstruing the intention behind all the negative feedback on the version 1.0 licensing.

Please provide a resolution to this ... fast. Really hinders the offering and selling of this add-on.

I completely agree. This restriction - especially in the light of the fact that there is also an absolute limit on 100 agents is extremely restrictive and prevents us from being able to deploy service desk in production.

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 understatement, 'cause it limits the potential of Servicedesk - even to the point that the added value becomes questionable.

Strongly agree.

We use JIRA Service Desk 2 with 10 agents and 50 JIRA Users. The JIRA Users are Service Desk Collaborators who help us resolve problems. I want to allow those Collaborators to be able to Edit Issues.

Why? For example, they often need to edit an issue to change its workflow status or tag it ("ready to push to QA server"). The ability for collaborators to edit, update and tag issues is critical for us.

But we cannot get it to work. The JIRA Service Desk documentation says it is a "major permissions error" to allow collaborators to edit issues:
https://confluence.atlassian.com/display/SERVICEDESK/Resolving+permission+scheme+errors
(That explanation in the bottom of the table does not make any sense to me.)

When I add "Edit Issue" to the permission scheme, it still does not work. It does not let collaborators edit issues. Similarly, I also want to add the "Assignable User" permission for collaborators, but that also does not work even if I add it to the permission scheme.

If anyone knows a work-around, please suggest it.

Strongly agree.

We would like to make use of this product but the restricted permissions break our current projects if we created a service desk from them. Only agents are given the ability to do routine actions like create links, assign users, transition to a different state, etc.

Wish you had kept the old pricing model but opened it to customers (would have been an easy fix). It remains as impossible to use as it was before. Too expensive due to the limitations of the over-arching service desk permission scheme.