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; } } }

Preventing users from changing assignee to 'Unassigned' if issue is in a specific status

Lucas Kröske

Hi,

as the title says we don't want our users to change the assignee to 'Unassigned'. We currently have five status defined and in only one of these status the assignee can be 'Unassigned'. In all the other status the assignee has to be set.

In the transitions we already made sure that the assignee is always set, but that's only one part of the problem. After the transition the user can change the assignee back to 'Unassigned' at any time, which we don't want. Is there a possibility to recognize changes made in fields to check whether they're 'valid'? We then could check if assignee is 'Unassigned' and revert the change depending on the status.

Many thanks in advance.

Accepted answers

Elifcan Cakmak

Hello,

I can think of three different solutions.

It is not a direct solution but you can use Allow unassigned issues property of Jira. But if you disallow, it will be global. So it might not be the best approach.
Also another option might be workflow properties. You can add a property to that specific status that block user to edit assignee. Check out this link: https://confluence.atlassian.com/adminjiraserver073/workflow-properties-861253674.html
Another option that I can think of is, writing a listener script that assigns the issue back to the previous assignee.

Regards,

Merle Fischer

Hi Lucas,

there is actually a couple of different ways to achieve this in jira, depending on your actual needs I recommend you check this thread and question: https://community.atlassian.com/t5/Jira-Core-questions/Can-you-stop-a-user-from-clearing-assignee-while-a-ticket-is/qaq-p/317586

Depending how well you know jira, adding a validator in the workflow step that checks for this field as required could be the fastes way of doing it, however if you never want assignee to be empty this could be a bit tedious, as you'd have to add this validator to every step. (https://confluence.atlassian.com/adminjiracloud/advanced-workflow-configuration-776636620.html)

You can configure jira to unallow this alltogether: https://confluence.atlassian.com/adminjiraserver073/configuring-jira-application-options-861253962.html however this means you have to set default assignees for each project which in turn can lead to one user getting swamped with everyone's unassigned tickets, as I said, depending on your needs there is different ideal solutions.

Hope this helps in figuring out what you need, best

Merle

All comments

Elifcan Cakmak

Hello,

I can think of three different solutions.

It is not a direct solution but you can use Allow unassigned issues property of Jira. But if you disallow, it will be global. So it might not be the best approach.
Also another option might be workflow properties. You can add a property to that specific status that block user to edit assignee. Check out this link: https://confluence.atlassian.com/adminjiraserver073/workflow-properties-861253674.html
Another option that I can think of is, writing a listener script that assigns the issue back to the previous assignee.

Regards,

Merle Fischer

Hi Lucas,

Hope this helps in figuring out what you need, best

Merle

Lucas Kröske

Hi Elifcan,

I guess these workflow properties only affect the transitions? The transitions are working fine, we prevent the users from changing the status, when the assignee ist 'Unassigned'. But after they've changed the assignee to change the status, they unfortunately choose 'Unassigned' as assignee.

The listener solution sounds perfect to me. Are these listeners recognize changes made in fields?

Lucas Kröske

Hi Merle,

the workflow works actually fine, one can only change the status, if field assignee is unequal 'Unassigned'. After a transition the users can then change the assignee to 'Unassigned', which we don't want. It's more a problem of the issue view/edit, users can set the assignee at any time to 'Unassigned', which is generally okay. But for most status, we don't want our users to be able to change the assignee to 'Unassigned'.

Elifcan Cakmak

Hey,

Actually properties can be added to statuses also. I don't know exact property keys but you can try it out according to the link I shared.

Yes, listeners listen for events, for example, in this situation it will look for issue updated event and your script will check if the assignee is changed to unassigned and change it back to the previous assignee. You may use script runner plugin for this or you can write your own listener plugin.

Regards .

Merle Fischer

Hey Lucas,

I figured as much, when I read your response to Elifcan, and yes, Event Listeners are the way you want to go in that case

you could find this useful: https://developer.atlassian.com/server/jira/platform/writing-jira-event-listeners-with-the-atlassian-event-library/

Joe Pitt

From personal experience with many tools, issues that aren't assigned to a person aren't worked. Allowing unassigned issues at all opens you up to no one being responsible for them. they don't appear in anyone's 'assigned to me' list.

Lucas Kröske

Hi Joe,

that's absolutely okay, since we have a filter for all unassigned issues. There is a person, who will evaluate and then assign them to someone.

Elifcan Cakmak

Hey,

Here is a link about how you can use properties on statuses:

https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

Regards.

Alexander Ziegltrum

Hey all 👋 @Lucas Kröske @Elifcan Cakmak @Joe Pitt @Merle Fischer

I'd like to pick up this topic again. For us it does not work, to add a validator step to each transition, as it would be way too much to do.

Has anyone found a way to use Adaptavists Scriptrunner for Cloud to solve this? We have this add-on in place, but yet wo do not have knowledge in creating scripts.

Our use case is the same as @Lucas Kröskein each status except "New" there must be an assignee set, issues w/o assignee are not allowed.

How can that be achieved?

Thanks, Alex

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server