Move an issue from JIRA Service Desk to JIRA Software

[Mark Everest]

Hi,

We've been big users of Jira Software for a long time now and are starting to look at the Service Desk application, however I have found one blocker in our testing.

Right now, our user access to Jira is open for anonymous users, but if you want to contribute to an issue you need a login. This is great because it means our Service Desk can close issues from their current (crappy old) system and create software issues in Jira, and the user can track the issue in Jira Software anonymously without needing a login as long as they know the URL (we have 500 staff but only 59 need a Jira Software login as contributors).

With the ServiceDesk application in Jira, in the event of a bug, the Service Desk can now "move" items from the Service Desk project to one of our Software application projects - brilliant!

However, with the application enabled anonymous users are now automatically redirected to the Service Desk portal if they don't have a Jira ServiceDesk or Jira Software license assigned - this is the issue. Users who create the ServiceDesk issues (i.e. the majority of them do not have a Jira Software license) cannot track the progress of their bugs when moved as they lost all anonymous access to Jira Software.

When an issue is moved form a Service Desk project to a Software project, how can the original requester track the process of that issue in Jira Software now?

Thanks

Mark

[Walter Buggenhout]

Hi Mark,

It looks as though you are trying to bend your use case to the limits (and even over) the boundaries of the application.

Instead of moving the issue to Jira Software, rather create a linked issue in Jira Software and use Service Desk Automation rules to make the Service Desk issue transition when the linked issue transitions too. That way, the status of your Service Desk issue automatically follows the status of your Jira Software issue. The customer can stay aware of the issue status through the customer portal (and Service Desk notifications) without the need to access the Jira Software issue.

[Mark Everest]

Hi,

I can see that would work, but it would not be suitable for us.

Firstly, if a software enhancement request is reported to the ServiceDesk, we want to move (or close) that call and manage it in Jira Software - sometimes low priority issues can hang around for months to be scheduled and we don't want those cluttering up the Service Desk queues and affecting SLAs.

Secondly, that still doesn't get around the issue that enabling Jira ServiceDesk removes the ability or anonymous users to see Jira Software issues - this is an absolute must for us.

Thanks

Mark

[Walter Buggenhout]

Then again,

If it is a must for you to track support in Jira Software, why would you even bother implementing Jira Service Desk? If I follow your story, you would only add the complexity that your Service Desk people need to move a ticket to the other system.

[Mark Everest]

Why would we not want Jira ServiceDesk?

Having one system as the front of IT should be a benefit of having both Jira Software and Jira ServiceDesk - one system to manage requests from users and potentially for other parts of the company too (e.g. Facilities, Catering etc.) Why have 10 systems when you can have one?

We want Jira ServiceDesk as it is far superior to our current Service Desk system which is old and rubbish. It isn't just for tracking software bugs, but think you are missing the point here, which is:

Enabling Jira service Desk stops anonymous access to Jira Software.

This is my issue, not the process needed, which what I am describing is less of an overhead to what we have to do now. For a ServiceDesk user to click "move" and chose a destination, is not a complicated process.

[Mark Everest]

Just to add - when I say "anonymous access" it's actually the wrong term - I mean accessing Jira as a user who does have a login, but who does not have a ServiceDesk or Software license assigned.

If you don't login, you can see software issues. As soon as you login, you get redirected to the portal.

We don't want users to have to log out and back in depending on what view pf the data they want.

[Walter Buggenhout]

Hi Mark,

Thx for the clarification. Since Jira 7, permissions to Jira Service Desk, Jira Software and Jira Core are indeed managed through Application Access. For Software and Core, this is attached to having licensed access. On one hand, when you log in, you are no longer anonymous. And on the other hand not having application access means you cannot access the features of the applications.

That's why the scenario I described earlier comes closest to what you are trying to achieve and is also recommended by Atlassian (about anonymous access to Atlassian products).

You can find tips on how to set up a recommended integration on this page.

To work around the queues issue, your queues are customisable so you can definitely find ways to keep your low priority change request issues out of the high(er) priority incident queues, so the work that is most urgent keeps flowing. Closing a service enhancement request and tracking the work in your Jira Software instance is a common practice that you can also manage through workflow enhancement. e.g. resolve you Service Desk request as 'confirmed' or scheduled. Through the linked issue you will have the benefit that you still know you can inform the customer who introduced the request that the issue has been resolved and released.

Unfortunately, if you want a logged in user to grant access to Jira Software, the user will require a license.

[Mark Everest]

Ok understood - this is a total blocker for us and I must say, a great shame!

I guess the only solution is to buy Jira Core licenses for all of our users, but at a price tag of $16,000 this is sadly not an option.

This means that we'll be looking elsewhere for a solution.

[Walter Buggenhout]

I understand your initial disappointment and am sorry that you feel this way.

As a last thing, I would recommend that in your search you still have a look into the linked issue option, as a small investment (probably no more than 1 day's work) in your workflow and SLA config and 1 or 2 simple automation rules will help you both save the 16k and have the tremendous value of getting all your users on a single platform.

[Mark Everest]

I agree that would work for the small amount of Software bugs logged via the service desk, but it will still mean that users who are logged in can no longer see Jira Software issues, which is a requirement.

I'm not prepared to give up yet though, so I may look into a way of exposing basic issue details from an internal web page by using the API.

[Ryan Finco]

I'd be interested in the outcomes of this.   My main "want" is the service desk PORTAL but to be able to manage projects using JIRA Software.   In short, I want a portal but NOT a helpdesk.  we don't care about SLAs and such - so all the default structure that comes with Service Desk, we basically redo all of it - don't work out of queues, etc. (we work from a backlog and kanban board).  We also can't use most of the stock reports as they're based on "time to close" and we need more project-like time management (we've plugged in tempo for worklogs).   

The problem is that the integration between these two worlds has some gaps, specifically around visibility settings for customers in the portal.   The fact that when WE create an issue in JIRA software, we have to falsify the requestor just so the portal owner (and contrary to rules around "Organizations" only the portal owner) can see the issue in the portal seems like a strange oversight for a somewhat basic request that seems, well a bit obvious.   It's also a bit annoying that now the rules don't apply and despite the organisation setup, only the portal owner can see this jira-created issue (which is the whole reason why "organization" as a feature was created!)

Anyway, I'll monitor this thread as I am curious regarding the outcome...     

[SL]

Hi @Mark Everest , did you ever find a solution or workaround for this problem?  We are facing the same issues.  Thanks!

[Mark Everest]

No and I have since moved companies and we don't use Jira ServiceDesk in my new place :-(

[Mark Everest]

We've deployed service desk and now our users are complaining about no access to Jira Software issues any more as we don't want to spend huge cash on extra licenses that will not be used.

[Mark Everest]

I've logged a product suggestion as 20028 but this site won't allow me to post a url

[Mark Everest]

Plesae vote for it if you can find it!