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.

[Merle Fischer · Accepted solution]

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

[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'.

[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/

[Elifcan Cakmak · Accepted solution]

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,

[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?

[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 . 

[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. 

[Lucas Kröske]

Hey Elifcan,

thank you for your link, that really helped! We've restricted the assignee to a group, but the assignee 'Unassigned' is still in the list of recommended assignees. I guess that is some kind of standard.

I think a listener is the only way to solve this elegantly.

[Elifcan Cakmak]

Hi, happy to help :)

[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

[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.