nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automatically assign a Fix version when specific groups create a new issue

Mike Applegate

Is there a way to set a default version for the Fix version field when specific user groups create a new issue? Basically, for non-dev team users, we do not display the Fix version. I would like this to default to the Backlog version in all of our projects. That way we can easily triage the issues/requests coming in without disturbing the developers. I guess we would want to modify the notifications as well so that only specific people get notified of new issues but I have not even got to that yet.

Any idea if this is possible within the configuration screens or is it something which must be customized? Or anyone have input on a different way to handle this similar process.

Thanks,

Mike

Accepted answers

JamieA

A little post-function script to set the fix version if the user is not in one of the groups, using script runner or other plugins.

NB Behaviour plugin won't work if the field is not on the screen. Sorry Jo-Anne, I seem to keep doing this ;-)

Personally though, backlog to me is anything not assigned to a version. If you had that convention then you'd just prevent the non-dev people from setting a version using the Schedule perm in the perm scheme.

All comments

Jo-Anne MacLeod

Behaviours plugin?

Mike Applegate

Thanks, certainly looks promising but I still can't figure out how to set the fixversion to a specific value, e.g. Backlog. There is a server scripting option which may do the trick but still trying to dig up specific samples.

thanks

JamieA

A little post-function script to set the fix version if the user is not in one of the groups, using script runner or other plugins.

NB Behaviour plugin won't work if the field is not on the screen. Sorry Jo-Anne, I seem to keep doing this ;-)

Mike Applegate

Thanks Jamie. I agree that an unassigned issue can be considered backlog. But I was thinking that we can sort of triage the issues/requests coming in from non-dev members to determine if the item should be added to the backlog for dev. So in other words, we have three groups involved in this scenario. 1. Support/power users - 2. Dev managers & QA team - 3. Dev/design team. I am trying to control the items exposed to the dev/design team by having the middle layer confirm bugs/features before adding to the backlog. It may get confusing if all items have an unassigned fixVersion unless we add some field to flag the issue as reviewed and/or confirmed. Anyway, not sure this is a reasonable practice but how we currently handle the inflow of bugs/features.

So this may require a seperate question but I will ask anyway. Is it possible to modify the notifications so that when new issues are added with an EMPTY fixVersion, the notification only goes out to certain groups or users?

Thanks again for the help, still learning Jira.

JamieA

Yeah, it is a separate question ;-)

So again, I'll say it's possible with one of my plugins. It may be possible with others too but I'm most familiar with my own stuff of course.

So basically you'd create two new events, and remove the "fire issue created" event from the create step of the workflow. Then you'd have two "fire event" post-functions, with mutually exclusive conditions. One for fixrelease present, one for not. (ie a) is: issue.fixVersions b) is: !issue.fixVersions).

In your notification scheme you just set which groups to be notified for each event. Sounds more complex than it is.

Mike Applegate

Sounds perfect Jamie, thanks so much.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

fix-version