I'm in the process of evaluating JIra Service Desk 2.0 and have a question:
Is this expected behaviour or should I check the permission scheme for a wrong setting ?
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.
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).
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.
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.
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.
Thank you Nic. I know how Atlassian wants us to work. But if you make a nice workflow it doesn't need to be separate. My opinion is that a company uses the different products how they need it, not how Atlassian wants us to use it ;-) and I think we pay enough for it. Or they just need to change the money making model and listen to want their users need and already ask for years. It's such a small adjustment in their software and will make a lot of user happy.
Indeed! We have both team in one company and it is duplicating the work for the developer to create a new ticket as the clone doesn't work cross project! We use linked issue but this only when the developer created the issue before hand. But what about the create issue via customer portal? Agent not able to assign non-agent(developer) and agent have to write a comment to have developer pickup the ticket and re-create a new one in Jira software and next to have it link...
So much work....are there any workaround?? We seriously need to push this bug/ enhancement.
Please be considerate. Thanks
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?
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)
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."
It's not only a question of licensing and the related costs. Developers shouldn't have/see the SD agent functionality. Developers are used to the standard JIRA UI, have their "My Issues - Inbox" with a lot of other issues from their project(s) they currently work on. Clone, Move & Link is a workaround that makes the incident "information stream" move away from the service desk: As an agent or service manager I no longer have a single overview about all the incidents, but have to check two JIRA projects at the same time. The customer is cut off from any comments and information exchange that takes place in the project JIRA. The incident has to be kept "unresolved" in the SD JIRA project until the issue in the developers JIRA project is resolved. The SLA monitoring and reporting will cost much more (manual) effort. This way JIRA SD is not leveraging the standard JIRA functionality and eventually lowers the overall value not only for the customer, but also for the agents, the service manager and the entire organisation.
It seems to me that limitations in the product were wired in, in order to address licensing and costs concerns. If is is about getting a bump on the collaborator licenses, since this group is now not just developers but also helping to resolve customer tickets, then a reasonable license cost on collaborators would be appropriate. But to assume a collaborator can only comment on an issue and never really 'work' on it is really short sighted especially with how projects that are both used for development and service desk incidents actually interact. Many of the examples in this thread point this out.
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 ...
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.
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...
+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...)
"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.
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?
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.
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).
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.
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.
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
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.
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.
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....
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.
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 :)
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Hi all, We are trialing Jira Service Desk for a large-ish, flat, team-based organization where members can serve on multiple teams. A few needs that are not out of the box... Assigning i...
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