Hi puchatekkubus632044760,
Sending messages upon resolving is the default rule. To transition issues, you'd need to configure the THEN part of the automation rule.

Cheers,
Lingbo

To resolve this issue I developed a simple service which adds label "watch" (and can also resolve issue) to any ticket in my SD project, if all underlying linked problems are closed. It works via Jira API.
This project is opensource and located here https://github.com/grisha0088/JiraWatcher.
It have a lot of hardcode by works well) It could be reconfigured easily. If you want to try I can help, it could be interesting for me)
grisha0088@gmail.com
g.dementiev@2gis.ru

It does NOT work. The only thing u can do with this is sent message but absolutely will not close subissues. Completly useless.

Hello Riya.
I have Jira Server in my company and this functionnality works with the Service Desk 3.xxx

When this automation available in Hosted / server application?

This feature is available in server roadmap functionality or not?

Hi, Update states that this functionality is available in the Cloud solution. Any idea when it will be available in the self-hosted solution ? Thanks

Toby, you can automatically transition JSD tasks when a linked task is transitioned. Check out the automation settings section of your JSD project.

Any update on the likelyhood that this will be added, as this would be very helpful for us?

+1 for @Rick Measham - I completely see the benefit in enabling the underlying linked problem to alter the linked SD ticket, however I do not believe it is possible to associate that function for every scenario where the underlying ticket is resolved i.e. it cannot be the case that the resolution of every underlying linked case, automatically implies that the linked SD case is also resolved.

What does makes sense is that the resolution of the underlying linked problem automatically transitions the linked SD case, to an appropriate new status on the SD workflow (as mentioned above) - maybe "ready for communication" or alternatively "linked case resolved".

The amount of safeguards that would need to be put in place to automatically resolve the linked SD ticket would most likely curtail it's implementation. However, the alternative option of (the underlying linked problem) automatically transitioning the linked SD ticket, would IMO make the implementation more likely.

100% on-board with the concept though!

I agree with Rick Measham comment.

ITIL or not, I don't think automatic resolution is the correct resolution to the problem people are talking about. Instead, we need the ability to transition linked issues as a workflow post-action.

The action would require

• one or more link types (so only particular linked issues are affected, eg. 'incident' related tickets and not 'duplicated by' related tickets)
• one or more workflow transitions (Eg 'ready for communication')
• A comment to be added
  • Whether to always add that comment

Now when the problem ticket is transitioned from 'tested' to 'released', any related 'incident' tickets attempt to transition using 'ready for communication'. Any tickets that can have that transition (based on their current workflow stage) would action that transition. The comment would be added to the actioned ticket (and possibly to all linked 'incident' tickets even if the workflow step couldn't happen)

(Obviously this could then cascade to linked tickets on that ticket)

I agree with Peter Straub on this. Our SD consists of up to 5 people, and thus we only need a SD license this big. We have about 50+ developers and even more potentially collaborators. So investing in a JIRA SD license this big would be a huge impact on our costs. For now we are not using the JIRA SD because this wont give us anything we allready have. We developed our own implementation of a service desk solution and are still using the old Vertygo SLA plugin to meet our SLA needs. We had a face to face meeting with Atlassian discussing our needs and disadvantages using the JIRA SD plugin in our organization. The solution for us is to let collaborators be assignable in the SD project.

If the Collaborators were assignable it wouldn't be necessary to clone/move a ticket to another JIRA project so that developers can be assigned to it an work on it.
This cloning/moving and the linking of a problem is just a workaround. In a customer environment where breaching SLA imply paying penalties it is very important that incidents can be resolved as fast as possible. This requires an SLA monitoring which is one of the functionalities that JIRA SD offers.
If the Collaborators would be assignable users, I wouldn't need to clone/move and link a ticket and "automatically resolve incident issues...." but would be able to resolve the incident directly within the Service Desk JIRA project.
So from my point of view, that is a integral part of the discussion here.

I disagree that this issue is not really important. It is perhaps not important for your usage of the tool but for others it is very important. Collaborators are assignable within the service desk but you have to pay for a license for them. That is a separate and mutually exclusive issue than the one discussed here.

I've re-read the description and I think that there is a misconception about the relationship between incident and "underlying soproblem".
An icident may be solved without creating a problem (see ITIL/ITSM for definitions): The service which is interrupted by an incident may be restored either by recovering the service or by creating a workaround. Sometimes, the service desk agent can solve the incident by himself/herself, sometimes he/she needs the help of somebody else from another team.
Whenever the incident is resolved by a workaround, the SD agent would close the incident (SLA met > no penalty; SLA breached -> penalty) and create a new problem ticket (> Problem Management) or link it to an already existing problem ticket. This problem ticket would be managed and eventually be resolved by the development team in their JIRA project.
The description above implicitly assumes that an incident is always cloned and moved from the SD JIRA project to another JIRA project whenever the incident can't be solved by a SD agent. I don't think that this assumption is true.

The cloning/moving/linking has major disadvantages:

• The customer can't use the customer portal anymore for his/her interactions with the Service Desk but has to use two different JIRA projects

• The Service Manager looses control about SLA monitoring and who is in charge of resolving an incident
• The incident history is split and from a Service Desk point of view lost.
• The customer portal's function "Find a solution" is getting useless, because a lot of information that should be available for a customer is now in another JIRA project.

To summarize:
I don't think that this issue is really important. Rather the "Collaborators" should be assignable within the JIRA service desk. This would help much more.

I disagree. There needs to be configuration that will allow issues to be auto-closed or to give the agent the ability to review and then close. This provides the maximum flexibility for users to determine how they would like their service desk to work. All support desks do not operate in the same manner.

I agree with Vojtech. Automatic resolution is wrong. There should be a notification that tells the service desk agent, that a Known Error or Problem has been resolved and that there are open incidents that are affected by this resolution or that there are Knowledge Base articles that have to be updated.
The agent - after consulting the customer - should decide whether an open incident can be closed or not.

"Automatically resolving" will affect parent issue even the agent/customer does not agree with solution in sub issues. - I mean its completely wrong.

The one way: The button for collaborators called "mark as resolved" or "need agents attention" should solve problem. The agent should decide if the answer and solution is enough or not. The only way for now is to watch tons of emails if there is something important.

Another approach: There should be some internal resolution status called mark for "approve" which would force the Agents to see the incident issue. The Agent will choose the final resolution for the customer. (And the internal resolution should be editable by collaborators of course)

You know what else would be cool? The ability to populate a jira ticket with some fields from the help desk request. (Specifically I'm thinking screen shots, url fields, and the requesting user id of the initial request)

If you guys can get this going, then I would not need to consider Zendesk. I need a more seamless integration between Jira and Helpdesk. The linking of issues is a good way to keep agents in helpdesk and developers in Jira, but having to remember to @mention is a pain. Also, If a developer closes a jira issue, it needs to close all related helpdesk tickets automatically and allow the dev to use a marco that tells the clients "Problem has been resolved" or something of that nature.

In our workflow the development issue would be resolved when development is done. This is different from the fix being available to the customer. Ideally I'd like to see versions added into the mix. For us the JSD ticket should be resolved automatically when the fix version set on the development issue becomes released.

I'd love to see tighter integration between JSD tickets and development issues though, this sort of things are absolutely the way to go with Service Desk.

It would be perfect

Just need to add a postfuntion that allow a jira issue to trigger a transition on a linked JSD tickets. Just pick the name of the link and add a comment (public or internal) to write on the JSD linked ticket (example, "The reported bug has been resolved by the Dev Team").

This would be great; we use Innovalog's 'JIRA Misc Workflow Extensions' which has a post function for transitioning linked issues - this works well in non-SD support projects, but fails in Service Desk because the developer executing the transition doesn't have the ability to trigger transitions in the SD project workflow (as they are not an Agent).

If Atlassian were to introduce a system for coupled transitions based on an issue link it would be AWESOME if that was just a generic JIRA feature, as opposed to being specific to SD.

Agreed. In both incidents this is a requirement.

Whenever issues are linked for whatever reason, the linked issues should behave as follows:
Cloned - 1 issue closed, the other cloned issue(s) should be cloned with a comment and their status changed exactly the same way, e.g.: Closed / resolved due to cloned issue no: xxxx that was closed / resolved with the following reason: abc reason 123.
And standard notification process must follow automatically for all cloned issues.

Related - Any related issues should be listed on a screen or a default comment be added to say. A linked related issue was closed, issue no: xxx with the following comment / reason: xxx reason abc.
And standard notification process for all related issues when a comment is added must be followed.

duplicates - will follow the same route as a cloned issue.

This will save time, increase productivity and keep record of changes.

Just a suggestion.

• New Atlassian user so please ignore if this already works this way...