I want developers to be able to transition tickets in JSM without having an Agent license

[Elaine McMillan]

As developers own and/or transition Change requests in JSM I need them to be able to do this without having to purchase an agent license (on top of their Jira license) to do this, is this possible?

[Mikael Sandberg · Accepted solution]

The short answer is no, in order to transition a JSM request you have to be an agent in that project.

[Mikael Sandberg]

You can learn more about the different roles in a JSM project here.

[Alex Koxaras _Relational_ · Accepted solution]

Like @Mikael Sandberg said, this can't be done out of the box.

What you could do, if you can afford an app like JMWE or Scriptrunner, is:

• Leave the JSM to agents
• Create a JSW project for all developers
• Create automations to create new issues to dev project, from JSM request types
• "Interconnect" the workflows of the issue types of two project among them, by adding post function to transition linked issues of a specific issue link type which will run AS an agent or an add-on-user (if applicable)

The above solution is time consuming and need huge maintenance. You could do it, but it needs an app and careful planning.

[Elaine McMillan]

agree with you, JSM offers so much promise but has a long long way to go t deliver on it

[Alex Koxaras _Relational_]

JSM is quite good and versatile, comparing to other tools in the market. It wouldn't be right though to grand jira users to be able to transition issues...

You could make them customers in the other hand, have them as request participants and expose the transitions you want to the customers.. 

[Elaine McMillan]

JSM appears to be designed by devs and facilitates heavy interaction with CI/CD so actually the old service desk model is arguably defunct and devs now are in the ops world   

[Nic Brough -Adaptavist-]

It's the other way around really, JSM is designed to insulate developers from end-users by putting an ITSM layer between them.  The main idea is the JSM portal is the route to communicate with end-users, but the Agents in the JSM projects act as a gateway.

The agents try to answer as many of the calls as possible, and then feed the handful of actual developer queries back to the developers by creating issues in the development projects, which is where you would tend to do the CI/CD pieces.

Yes, you have DevOps where developers do indeed work closely with end users, but JSM isn't for that, it's for helping people and getting stuff done in the ITSM world, it's not intended for developers!

[Elaine McMillan]

well if the boundaries of shift left are to be pushed then the "ITSM layer" need to be knocked down 

[Nic Brough -Adaptavist-]

Argh no.  ITSM is about planning, delivering and supporting IT services.  Without an ITSM "layer", you simply can't function.  

Simple worked example - you put a developer in a room with a bunch of financial traders.  Can that developer handle every single IT related problem they might throw at them?  From "power cut", "server down", "internet out", "my laptop is broken" etc.  

No.

(I use that example because that's what a DevOps team did to me 25 years ago (not that it was called that then), but it was ok for me because I could refer everything else I wasn't there for to the ITSM layer

You need the ITSM layer to manage the IT services, otherwise, you will get absolutely nothing done. 

[Elaine McMillan]

humm again all about the use cases and allowing that a company can have multiple JSM projects  to bring about work efficiency (not all external customer facing). In the SaaS/PaaS world you don't want walls/ITSM layer within the org and why duplicate tickets to Jira Software projects if code dev work is not required but dev knowhow contributes to the resolution.

[Nic Brough -Adaptavist-]

I am not happy that I have to day this, but your comment does not make any sense.  I can not see what you are trying to say (there is something there, but I can not read it from your writing)

[Andrew Laden]

Too bad you are cloud, else you could look at

https://marketplace.atlassian.com/apps/1212224/teamlead-helpdesk-for-jira-customer-portal-sla?hosting=datacenter&tab=overview

You can look at 

https://marketplace.atlassian.com/apps/4832/enterprise-mail-handler-for-jira-jemh?hosting=cloud&tab=overview

which might be able to allow you some flexibility if you interact with jira via email.

You can also try using automation. Have a custom field dropdown that matches your issue statuses, and when the custom field gets updated, have an automation trigger on that update try to transition the issue to the matching status.

[Elaine McMillan]

I like the alternate trigger idea but as they don't have an agent license they can't edit to update custom field value BUT would you know if a slack integration or alternate trigger  could use a system ID to perform a field update on behalf of a person?

[Andrew Laden]

I am an on prem user, not a cloud user, so I can't speak for cloud implementations.

That said, usually with automation, you can specify what user to run the automation as. You can can make a "System ID" that can run the automation (for example, we have one called "JSM Robot") . But that system ID has to have a JSM license. So you would still need to use 1 license for that user, but that's better then having to license them all.