I'm in the process of evaluating JIra Service Desk 2.0 and have a question: * when I try to assign an issue to a user who is not an agent I get 'user cannot be assigned issues' , even though the user is an assignable user according to the permission scheme (ie: has the 'developer' role in the project roles and the developer role has the 'assignable user' permission) Is this expected behaviour or should I check the permission scheme for a wrong setting ?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

assign issue to non agent

Andre van der Elst

I'm in the process of evaluating JIra Service Desk 2.0 and have a question:

when I try to assign an issue to a user who is not an agent I get 'user cannot be assigned issues' , even though the user is an assignable user according to the permission scheme (ie: has the 'developer' role in the project roles and the developer role has the 'assignable user' permission)

Is this expected behaviour or should I check the permission scheme for a wrong setting ?

Accepted answers

Geert_Graat

Hi Andre,

This is the expected behavior. In Service Desk projects, you can only assign issues to agents. People in the Developer role are probably collaborators, meaning they can only view issues and add attachments and internal comments to them. See https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+permissions for more information.

Regards,

Geert

All comments

Geert_Graat

Hi Andre,

Regards,

Geert

Andre van der Elst

also, the user I'm trying to assign an issue to is shown as a 'Collaborator' on the People tab. (the user became a collaborator directly through the permission scheme etc.)

Andre van der Elst

thanks for the quick answer. This probably means we can end our evaluation though sad

Geert_Graat

The question is what you want to accomplish using Service Desk. We use it for our support department which handles all customer communication. In case development is needed, an issue is cloned to a development project.

Andre van der Elst

our project-managers/support-staff would like to see SLA reports, so we thought we could get away with getting agent licences just for them and not for every developer. But cloning issues and copy/pasting comments back and forth just to get around a license restriction is not something I'm going to pursue. Anyway, there's a few more things we're going to try out before we stop eveluating. (cross-project SLA reports is one of our requirements)

Leevi Graham

This is a deal breaker for me as well. I want a couple of agents assigning tasks to the relevant developers and having the rest of my team take action on technical issues. Cloning issues is going to be a big overhead.

Jeff White3

Is it even possible to 'clone' an issue to another project as described above? I know that I can move an issue from a SD project to another project, but that effectively leaves no trace for the customer in the SD project? but I'm not sure cloning will help either. I don't see how to clone a source issue to a target clone issue in another project.

Carl Madson

This is nuts. Any intelligent product or system engineer would ask the user community what their typical workflow might be, and they'd surely hear "Customers send us requests for help, which we assign to developers." Nobody I asked said "I'd want to create a new project to manage those issues" or "I'd take in the requests and copy them and convert them to internal issues" or "I'd make everyone special agents" or any such nonsense.

Take an existing team of developers and a JIRA project with all of their issues. Add a connection to the customers. The logical integration should be clear – not two walled gardens with some interaction manager copying requests and tossing them over the wall, and then copying status information manually into comments in the original requests. Who thought that was desired? Who told you they wanted that?

Now I have an existing project with broken assignments to existing developers just because I added Service Desk to the project. Even old issues can't be assigned to valid and (supposedly) assignable members of the Development role and developers group. Tell me that's a feature.

I've recommended JIRA to various company teams for years and have used it actively in many ways, but you've lost me completely with this. It's absolutely the opposite of what I was hoping for, and not at all what I've come to expect from Atlassian.

walter barrios

Jurgen Imbrecht1

Hi, is there anybody who found a solution to this problem? Maybe a work-around or another plug-in?

I'm a service desk manager, I handle communication with the client.

When an issue is raised it's automaticly assigned to me.

I acknowledge the issue, if it's a problem in the code, then I assign it to the right developer so he can fix it.

Then he assigns it back to me and I finish up with the client. I'm the Service Desk Agent, he is a collaborator.

I would think this is somewhat a standard workflow?

But this isn't possible in the current configuration. I would have to change all my colleague-developers as Service Desk Agents. And thats kinda strange because they are not agents, they are not expected to interact with the customers.

I'm surprised to see a behavior like this in a bug-tracking tool.

Anybody with the same problem as me and found a solution?

Or maybe somebody from Atlassian who has a solution?

Clemens Perz

Huh, very weird! Renders the whole system useless. You have roles and permissions and you cannot set them up as you like - the given behaviour is internal, not to be seen in the permissions.

I added a user to assignable users and guess this should mean I can assign issues to him. Pustekuchen! Does not work as reflected in your permisson settings. Very confusing.

Thou shall earn all the money you want, but please dont make the product kaputt for it!

And why can I actually activate a service desk for an existing project without beeing warned that the behaviour will change drastically? Let me see what happens once I deactivate the service desk - will there be a proper cleanup or is it broken?

Very very very weird idea.

BTW, not surprised that the number of comments from atlassian guys is pretty low ... smile

Stanislav Rehak

I have to agree on this one! 2Atlasians: Is there any chance this will be possible in future? Collaborators should be able to log work on request as well as to be set as Assginee.

William Rojas (

Have to agree on this thread, not only is this behavior misleading, but it looks to be 'undocumented'. Even if I remove the Service Desk Team role from the Assignable User permission and keep Developers and Collaborators only, once the development project is setup as a Service Desk, I lose the ability to assign issues to Developers, unless those developers are also given service desk agent permission. The code seems to be hard-wired internally to check for that user being part of the Service Desk Agents group regardless of the permission scheme defined for the project. So in reality this indicates that one would likely never enable service desk features enabled against existing development projects... not if every developer in that project is now required to have an agent license even if they have no intention to perform any Service Desk functions. This should at least be more clearly documented. Especially since it's not quite simple to undo. Can someone from Atlassian comment, is this how one should advise clients then: "Don't use Service Desk with existing development projects, unless you purchase agents licenses for each developer."

Bart Van Belle

you also got my vote on this one !

Stanislav Rehak

I have to disagree on this one! It is totaly unexpected... and worst illogical. I hope Atlassians will reconsider this.

Roman Fordinal

Rehak, illogical when you thinking about it as user (agent or developer). but because for Atlassian it is not about customers (we), but about money, they are shitting on our heads. yes, it is absoluttely logical to have agents to communicate with clients and developers to resolve issues and log work into issues. but: less agents, less money for Atlassian. We are solving this weird sittuation by copying issues into projects (and because "copy" feature is not available, we are copyiing it manually).

Roman Fordinal

btw: and cloning is available only into same project, also customer is receiving confusing message about creating duplicate issue in Service Desk! after cloning is available "move" function.

Roman Fordinal

"they can only view issues and add attachments and internal comments to them"
i was always thinking that developers are for developing on issues, also logging work.

Enabling ServiceDesk for project has serious consequences!!!
Developers are not longer able to work on own issues!!!

And that is a blocker bug.

Michele Longhi

Just crazy. Developers and Agents are two different things. Developers have to be assigned issues. It will be logical the opposite: Agents cannot have assigned issues, but only assign or collaborate to the issues.

Bart Van Belle

+1 for Roman.

Indeed, a "normal" workflow would be that tickets can be assigned to a 2nd level support team (eg. developers) when the 1st line support (typical helpdesk) decides to escalate the ticket. There should be a transparant way that those tickets can easily be escalated to another level and that then these "collaborators" (developers) can transition the issue through the (escalated) workflow and indeed besides logging comments also be able to log their work spent. Atlassian has a really strong potential Helpdesk solution in house that can compete with the "older" more constituated helpdesk systems out there, but the strict licence policy with agents-collaborators etc makes it difficult to get a solid foot in the ground for companies (like ours) that are looking for a solution to both use JIRA for helpdesk (customers) and development. Indeed there sould be a distinction that "agents" deal with the "end users / customers", and "collaborators" are assigned to a ticket on a 2nd line support level, but it is very strange and really uncomprehensible (besides ofcourse the extra licence fees Atlassian can collect from this (weird ?) licence policy) that on a "normal" JIRA project users in developers role can transition issues through a workflow, log work etc... (if ofcourse the project permission scheme allows them to).

So people at Atlassian: please reconsider this because with Helpdesk in your product portfolio you have a REAL strong product to compete with the "big" Helpdesk systems (like BMC Remedyforce, CA, etc...)

Roman Fordinal

nope. cloning into another project is not possible (crazy, uh?). only in two steps: 1) clone issue into same project (and customer are receiving duplicated notification about issue creation ) 2) move cloned issue into another project

Bart Van Belle

an other "alternative" could be that you use for instance the "create on transition" plugin (Bob Swift), so that you can add a transiton to your servicedesk worfklow to "escalate" a ticket (create and link a new ticket to the servicedesk ticket) to eg. a development project. You can than automatically copy subject, summary and other fields from the "parent" ticket to the "child" ticket. So when the "child" ticket is solved, you can eg. post a comment / email to the "parent" ticket so that the helpdesk agent is aware of the fact that the ticket got solved by the 2nd line support team. Not "ideal" but can be a solution...

Todd Sherman

This totally pissed me off!!! I spent hours trying to figure out this permissions problem, thinking I set something up wrong only to read this?

russell illsley_mynxet

Its just a way for Atlassian to force us to buy more licences.

this is poor.

its normal in any real IT world an IT Service Desk operator would assign a ticket to an Engineer to execute - two separate functions who would both work on the ticket.

Clemens Perz

I am actually not so worried about the numer of licenses. If it would be like you need to have the user who works on these tickets in group foo, otherwise he cant, and the members of group foo is what is counted in the license ticker and you pay what you need to pay - or decide to use another product, I would be fine.

What makes me mad is that I cant change this intensionally as broken implemented process. Where everywhere else in JIRA I can customize everything, here even my changes will not change anything. This is bad. And its not what JIRA stands for.

Just make sure people can work the way they want to with your product. Should be rule number one. Or not?

russell illsley_mynxet

You have never used JIRA Agile then.....

Clemens Perz

Does it have similar issues or restrictions? Would be nice to know. So far I did not run into them.

Anonymous_c2ydwo

The new version (Agent based) Service Desk is total useless as far as permission set up is concerned. Just like someone above stated, They have the roles and the permissions, but you can't set them up as you like. Totally confusing and frustrating. I'm in the process of evaluating this new agent-based version, I've been getting permission related issues constantly. I think non-agent based version work perfectly fine. It's more straightforward, easy to follow as far as permissions, roles are concerned. What you see is what you get unlike the agent-based (what you see is not what you get).

Odwin Rensen

This tool has such create potential and as a servicedesk ticket platform does what it needs to do, but in real life it often does not stop at the servicedesk. When it is code related or the issue needs a higher tier of knowledge these issues need to be assigned to different teams outside service desk.

Not being able to do so, totally renders this tool useless for us.

William Rojas (

Andre:

The global permission scheme that JSD 2.0 introduced requires that a user be in the service-desk-agents group before you can assign a service desk issue to that person -thus taking up an agent seat in your JSD license. Collaborators are only allowed to comment on an issue, but cannot be granted assignable user... even if your permission schemes says so, the assignment won't be allowed.

Markus Dengler

totally agree - absolute useless if it is not possible for collaborators to log work at least;
Assigning JSD Items to developer or creating a related issue would be great

Joe Barneson

FWIW – I had stories with subtasks outside of my service project that I "moved" into the service project. The subtask's assignee was a not assigned as a service agent and was retained as the assignee.

This is a terrible workflow to retain assignee's in the service center – but I wanted to share out if others felt they could tolerate it.

I too, like many others, will not being using the service center until it allows my collaborators (team members) to be assigned to subtasks.

Clemens Perz

I see there is a new Service Desk 3 coming - tried to figure out if the behavior has changed by reading the information available, but it seems not.

Would be nice if ppl who did the upgrade could share if there has been a change of mind. Just out of couriosity, as my management has already decided to drop JIRA in favour of a much more expensive product that does not impose a certain workflow for the sake of a doubtful sales pitch.

unknown

I understand the reason for only allowing agents to be assignee of a request, as they effectively manage the request but would Atlassian consider allowing sub-tasks within a service desk project to be assigned to anyone with the 'Assignable' permission.

My use case would be:

I have a workflow status called 'Bug fix in progress' that requires creation of a sub task assigned to a developer to be transitioned to and can only be transitioned to 'Bug fix complete' when the sub-task is complete.

This overcomes the 'developers' exclusion case but allows separation of front line agent workflows and that of any support or operation workflows that may come into play to resolve the request.

Another thing, what if 'Request participants' could transition? This would allow and agent to add a participant at a particular status and they can then transition when they have completed there part.

Bart Van Belle

First of all, I don't understand Atlassian's "logic" to allow only agents as the assignee of a SD request (except for the licence cost ofcourse) nor the "logic" that "collaborators" can only comment on SD requests (to collaborate goes a little bit further than just "commenting" as far as I am concerned. What we at our company intend to do is to have the SD project in a *separte* JIRA instance with limited numbers of "agent licences" (so that they can act as the 1st line support) and then have another *separate JIRA instance* installed where an SD request can be "escalated" to (meaning a new JIRA ticket is created in the 2nd instance with a copy of all the data of the original SD ticket and then fully syncrhonized bi-directionally). So the 1st line support agent would then in a workflow "escalate" the JIRA to the 2nd JIRA instance where the ticket *can* be assigned to users with *assignable" permission (logic) and when done/more info needed can be replicated back to the SD JIRA instance. There are some commercial tools / plugins available in the JIRA community to do this replication which are *far* less expensive that let's say buy a bunch of "agent" licences for your developers....

alexandru pau

We were also planning to start trialling JSD and realised the problem in keeping the 2 systems interconnected by the limitation added on Agents vs Developers roles.

Since the only interaction a Developer could have with JSD tickets is through comments, he would further need to use linked issues following regular JIRA workflow which creates an overhead and latency for Agents activity. This we see it as the main problem, since Service Desk operators would need to constantly check linked issues or comments to proceed with further actions on main JSD ticket

After further investigations we ran into a possible fix added by Atlassian through JIRA 7.0.0-OD-08-002 bux fix release

Basically it relates to AUTOMATION feature which could (hopefully) trigger a when / if / then effect from linked JIRA issue to JSD ticket (from example if a linked issue is closed then the main JSD ticket does a transition to it's own workflow status)

Find more information here until will be able to provide a feedback based on self confirmation

https://confluence.atlassian.com/cloud/18-october-2015-to-24-october-2015-780870807.html

http://blogs.atlassian.com/2014/12/collaborate-developers-using-jira-service-desk/

Sam Bosell

2.5 years later and I realize the market for the service desk is not the same as the market for JIRA in general. Most software support systems need the ability to assign a developer the ticket and the service desk does NOT allow that unless the developer is an agent. I doubt any of us need the developer to interact with the client (comment internally only) but Atlassian's business model, in this case, goes against their core customers. It will only end up hurting them in the long run.

Jan Odvárka_ez9ckc

I was able to implement JIRA SD into production with system of SD issues and linked issues into the separate projects for HW engineers/ SW administrators / etc.

Everything is now working somehow, JIRA SD with Insight CMDB and custom fields is able to let me create and choose everything.

Powerbox SLA is able to show SLA on Service Desk issue to non agents assigned to linked issue.

Automation for JIRA is able to provide comments copy/paste from linked issue to main issue and than send email to the Service Desk mailbox.

I can send notification with variables in subject and body, but with MANDATORY PREFIX, which causing a lot of problem for many of our customers.

I will kill for possibility to let 2nd/3rd lvl support to update statuses/comments on the main issue without need to make two tickets for 1 issue.

Jack Brickey_h10pa4

I assume you mean 'and not have to give 2nd/3rd level support users agent properties'. If you want user to be able to edit/transition they have to be agents.

Jan Odvárka_ez9ckc

Well most typical use case

SD agent creates an issue

SD agent assign himself as an "Agent"

SD agent choose SAP administrator named for example Bob from the list and assign him as a "Resolver"

we are still on the same issue

SD agent has own permissions to use transition to go through whole workflow or only for defined steps (defined by admin)

Resolver Bob has his own permission to see running SLA, all details, add comments, updates, but he has also possibility to use transition for changing status in the workflow. This could be restricted by mandatory approval from Service Desk agent, but he has to have rights for transition from Created to In progress, In progress to pending (waiting for customer) and from In progress or waiting for* to Resolved.

Each transition done by Bob can be set as "have to be approved by assigned Agent, so Atlassian will still have almost the same licencing policy restricting to non agents to be fully operative in SD issues/projects.

I hope that I wrote it clear

Kind regards

Jan

Jerry Ryan Ishmael

tldr;

I skimmed through most comments but I don't understand why those issues that need 'escalation' to a developer do not have a linked developer ticket through JIRA?

Desiree Graste_yr7yl3

Anyone knows where atlassian stand on this one? I still totally agree with Carl. I'm running in this problem already a couple of years!

Nic Brough -Adaptavist-

They expect you to use "create related issue in development project". The idea remains that the SD issue is for talking to the customer and tracking the request, and if work needs to be done by developers, it should be created separately so the dev team can manage it in a development process.

Rich Hale_mvr7ir

We have a bit of a different model:

Agents (x17 to 30) will talk with customers, and always enter the issues. They didn't want to work through the limited customer portal view, so I needed to give them permissions at the internal project level also, and customize that "create" issue screen, with about 10 required fields.
Developers (x3 to 6) will work customer issues directly. Thus creating them as JSD Agents made the most sense.

I've priced a few service desk products, and I'm thinking even having the developers as agents, but having these two systems so tightly integrated into a single (SaaS) solution, is still a great savings over other platforms, all things considered.

Keeping in mind, JSD is designed specifically as a customer oriented portal with feature sets around that solution and set of problems, linking these issues to solution oriented JIRA tickets in other projects is really not a bad idea, nor too time-consuming. You can allow developers to "view" these JSD tickets as part of that model.

dchisholm

We have added a custom action on our software projects called "Add as Participant". If a development issue is linked to a JSD issue, this action will add the developer as a participant to the JSD issue, and that allows the developer to add public comments via JSD's portal view to collaborate directly with the customer.

Rich Hale_mvr7ir

good idea

Nicolas Millier

@dchisholm your idea was interesting and before trying to make a custom action I try to add a simple Jira user (not JSD agent) as a Participant on a task but I still don't have the button "Share with customer" under the comment field but only "Comment internally".

Is it still working for you ? If yes did you change any user right or make configuration change ?

Thanks for your help.

Nicolas

Patty Yost

Having read through most of the comments on this thread, the underlying theme seems to be that Atlassian wants you to have a Service Desk license for any user that is assigned to an issue. BUT -- they not only require a license, they require that users be in the Service Desk Team project role to be assigned to an issue!

We created a separate project role in order to limit the permissions for a group of users, but did give them 'Assignable User' permission AND gave them a Service Desk license. We can't assign tickets to them unless we add them to the Service Desk Team!! Please fix this, Atlassian!!

Patty Yost

I was wrong! We gave the 'Service Desk Agent' permission to this group and they can now be assigned issues, yet still have the restrictions that we put in place on other permissions.

Ismael Garcia_wyfokh

Nothing has change from the original post on this topic, is very sad to see atlassian doing so wrong, very disappointed.

Fuad_Hasanli

Hi, not only me have this problem. Customers raises request via Customer portal. Our agent created duplicate of request in software or core project. Let's say it OK. In duplicated task our developers or support employees works on tasks, and customer doesn't have any information what going on in background. It's makes complicated for customer to get info about his/her request.