Components default assignee clashing

[Javier Cárdaba]

I am reviewing "Managing components" section (https://confluence.atlassian.com/adminjiraserver073/managing-components-861253335.html). 

Talking about "Selecting a Default Assignee", it is said: "If an issue has multiple components, and the default assignees of components clash, the assignee will be set to the default assignee of the component that is first alphabetically."

The question is: if an issue has 2 components (one with "Unassigned" default assignee and one with a specific person).... will they clash? 

Bonus question: which addons you recommend to enable more functionality on assigning issues based on components?

Thanks!

[Deleted user]

Hi @Javier Cárdaba,

Tested your question;

The question is: if an issue has 2 components (one with "Unassigned" default assignee and one with a specific person).... will they clash? 

The result was the issue was left unassigned.

If you require a more detailed aspect to Components my suggestion would be to trial: https://marketplace.atlassian.com/apps/1211548/subcomponents-and-component-versions?hosting=server&tab=overview 

Hope this helps

[Jack Brickey]

Danny, interesting for sure. i would not have guessed (obviously :-)) that! Unassigned is the same as empty so that wouldn't be the way I implemented. 

[Javier Cárdaba]

Hello @[deleted]. In fact we are using the Cloud AddOn: https://marketplace.atlassian.com/apps/1214373/subcomponents-for-jira-cloud?hosting=cloud&tab=overview

We have built a hierarchy to work the following way:

• Ticket is created assigning the fist level component (1st level of support).
• A dedicated group assigns the correct child (2on level of support).
• Only the child components have named assignee. The first level are configured to leave the ticket unassigned.

I am not able to see how this addon is helping me in this targeted behaviour. Thanks in advance!

[Javier Cárdaba]

Thanks @Jack Brickey for your reply. Which approach would you use?

[Jack Brickey]

Not exactly sure w/o fully understanding your environment and process but here is something that comes to mind.

the issue here is that Components field can have more than one entry. So your could enforce a process where the user needs to replace the current component w/ a new one. This likely won't work all of the time given humans are involved. 

Another approach:

Create a custom field (drop down single select) to replace what you are trying to do w/ component. It can default to '1st level of support' or whatever. Users would be required to update the field just like they would add a component to pass the issue off. Add automation using something like Automation for Jira or even the Lite version that would reassign the issue whenever the custom field is updated.

I think that is where I would start based upon what i'm reading here.

[Iain McCarthy]

Just as a point of interest, I just tested this on our Jira Cloud instance and got the opposite result. 

Created: Issue with two components, one with an unassigned default and one with an assignee.

Result: never unassigned, regardless of component alphabetical order. Always goes to the named assignee.  

If both components have named assignees the alphabetical component ordering is honored. 

[Ajibade Momolosho]

I tried this out too and got the same result. 

[Jack Brickey]

No. If one component is unassigned there should be no collision. Easy to test and verify. 

Sorry, I can’t help on the bonus question. Do you have some specific requirement. Might not need an addon.