developer/collaborators and service desk workflow

[Mark Anderson]

Hi All

Fairly new to JIRA. We have several software projects and developers. these all work great.

We've just added service desk which we like, but the workflow with developers/collaborators seems iffy'

One shocking commission (unless I'm missing it: highly likely) is that there doesn't seem to be a way to restrict SD users (or even agents) to only see tickets assigned to them. Is this possible? We were hoping we could use that for developers.

So we thought we'd use linked issues: when an issue comes in for ProductX and it needs to go to dev for assist/bug fix, create a linked ticket. there are several issues with this (that i can see, hoping it's configuration):

1. Developer can't see comments on original SD issues, so they can't see what SD agent has already tried with reporter.
2. When ticket is marked as done in software project, i want it to marked as complete in SD (or at least moved to a status such as "pending confirmation". Maybe I can do this in a workflow, but these seem very limited compared to on-premise install. (Can i update the issue it was linked FROM in a transition?)
3. From Service desk, I can't see who the linked ticket is assigned to or add comments for them (for example reporter calls with further info while it's with developers)

Assuming these are not config issues, it's a bit surprising that a service desk solution that came from a dev management solution is missing these

Anyone got any good suggested workflows?

Thanks

Mark

[Steven F Behnke]

I think something like this is simple to implement and simple to use.

User Picker

Allow Service Desk agents to grant visibility to a single user of the developer groups

1. image2016-8-20 10:18:40.png
2. image2016-8-20 10:18:50.png
3. image2016-8-20 10:18:54.png

Group Picker

Allow Service Desk agents to grant visibility to entire groups of developers

1. image2016-8-20 10:19:34.png
2. image2016-8-20 10:19:40.png

Issue Security

• Set up the default Roles: Customers, Administrators, Team.
• Add our Developer and Developer group fields.

image2016-8-20 10:19:58.png

Result

Only issues where the developer or their group are assigned will see any issue. You could consider adding them to your notification scheme now too, the User or Group custom fields.

[Steven F Behnke]

Notice that since there's a single, default level, we don't need to rely on changing security levels to control access. This is friendly because the implementation is simply a matter of introducing these users to the fields: They will have access at that point. We can control these fields with Post-Functions.

We can't use the Permission Scheme for this because of https://jira.atlassian.com/browse/JRA-37117.

[Mark Anderson]

thanks a lot Steven

Was just working through this. Unless I'm missing something, it doesn't seem too much different than changing a security level manually (i.e. an agent still has to remember to do it)?

Am I missing something?

Regards

Mark

[Steven F Behnke]

I see. I must be dense! I never understood that you wanted to automatically make this happen based on another selection. Unfortunately I don't think this can be done without special customization or a custom plugin or script.

[Mark Anderson]

That's what I feared. i wish they'd support groovy in cloud and allow security level setting in Automation/Post functions

Thanks for the suggestions

[Steven F Behnke]

I believe Adaptavist announced JIRA Cloud Script Runner so hopefully we get that soon. They do need to rewrite it from scratch, there's just no way to install the usual scriptrunner into JIRA Cloud.

[Mark Anderson]

good to know.

it is frustrating having different functionality in the two platforms. Looking for a root cause analysis plug-in right now. Found 2 great ones: neither works on cloud version 

[Steven F Behnke]

The new Connect platform is just so new, while the P2 platform has so much history. I think the market will unify as developers figure out how to leverage both, but it does take time. The split certainly is annoying is what I agree with.

[Steven F Behnke]

Why can't the developer see the comments on the original SD issue? Why can't the Agent see the details on the linked development issue?

Why do you want to restrict who can see what? Haven't you investigated Issue-level Security?

If you want the linked dev issue to transition the service desk request, have you investigated Automation Rules which offer this specific feature?

[Mark Anderson]

thanks for reply Steven

Why can't the developer see the comments on the original SD issue?

Developers do not have access to service desk (if we could restrict their view to their own assignments, we would consider to, but still then, support OWN the issue, dev are just working on it, and support may need to install a patch to close)

Why do you want to restrict who can see what? Haven't you investigated Issue-level Security?

1st part: business requirement. 

2nd part: yes I did, but I can't set a security rule on a transition or component change, so I have to set up a "see all" issue scheme" and agents have to remember to remove that if they assign a ticket to developers. I can't find anyway to automate this level change in cloud version

If you want the linked dev issue to transition the service desk request, have you investigated Automation Rules which offer this specific feature?

I was actually looking at that this morning and will investigate further, but I wanted to figure out if we could come up with a workflow where dev can work on just their tickets in service desk

[Steven F Behnke]

A possibility here is to add a layer Issue-level Security into the mix. We can easily make this work for teams or assignees. I think this is something I could walk you through. We have to think outside the box, because yes you ran into https://jira.atlassian.com/browse/JRA-9107. There's no post-function to set the security-level. I have one question: Do you want to assign this to the entire developer group or do you want to assign this to specific assignees?

However keep in mind, if you use the automation, then the developer group can have independent processes, screens, and reports.

[Mark Anderson]

Thanks Steven, i voted for the issue above

Not clear on what you mean by "this" in "Do you want to assign this to the entire developer group..."

If you're talking about the issue, then a single developer

if you're talking about the security scheme, then the entire developer groups (we have several)

Thanks

mark

[Steven F Behnke]

Sorry, I mean do you want to grant visibility to issues on an issue/assignee basis or do you want to grant visibility to issues on an issue/developer group basis.

[Mark Anderson]

Probably issue/assignee, but it might be nice to have both options