Control Component Field Ordering

[Coby Fuller]

I have a request from a team that is using multiple components (at times) for a single issue. I have added a post function step in the workflow to auto-assign to the component lead when transitioned to a certain status. The problem is that the components are sorted alphabetically and not in order that they were added, so the issue could potentially be assigned to the wrong component lead. Has anyone else had similar requests and/or is anyone aware of a possible solution to this request?

[Nic Brough -Adaptavist- · Accepted solution]

I'm afraid there's no way to do this - Jira's component field is a simple unordered list of items, there's nowhere to store sort information like "date/time added" or an arbitrary ranking for them.

You'd need to write a new field type to enable this!

[Coby Fuller]

I was afraid this would be the case, but wanted to make sure I had exhausted all resources before reporting my answer. Thank you for your response.

[Coby Fuller]

And just to clarify, when you say 'a simple unordered list of items', this field IS ordered alphabetically, but there is no way of manipulating this order?

[Nic Brough -Adaptavist-]

Sorry, I was not as clear as I could have been on the ordering.  I over-simplified!

In the database, the list is unordered.  If you ask "give me the list", you get a list, but there's no guarantee of how it is ordered.  Generally, it'll come out in the order components were added (for example, if I create an issue with "hops" on Monday, adding "malt" on Tuesday and "water" on Wednesday, I'd probably see [hops, malt, barley], but if I added "malt" and "barley" on Tuesday, I've no idea which way around those would come out in the list)

However, Jira's display functions are coded to sort that list (alphabetically as you say) before they get shown to the users.  And in some places, the edits might also end up sorting what is put back into the database, so your raw data suddenly changes order as well!

I've not spent much time with this, I don't know what the "rules" are, just enough to know it's sorting alphabetically because there's nothing else it can sort on!  (Well, not quite - you could argue it might be partially sortable by lead, and it could be sorted by the age of the component in the project, but I don't think either of those are better than a simple alphanumeric sort - I'd have to explain them to people, unlike alphas)

[Coby Fuller]

Thank you for the clarification and for your help.

If interested, I've decided to use a workflow validation rule that will display an error if more than one Component is selected. The auto-assign post function is very early on in the workflow (first transition not counting create). So the idea is to not allow more than 1 component until analysis is completed in the first status. Once the issue has been transitioned to the 2nd status in the workflow they can add as many components as they would like.

Again, thank you for taking the time to help out.

[Dan Graydon]

Our approach - Stories can certainly span multiple components but the sub-tasks should be broken down into a single component and assigned to single member of the team which can then be auto-assigned as you mentioned.  We usually clone stories so they map to only one component.  We do this because each story, for each component, typically goes through some level of independent unit and QA functional testing.  In some cases we have dependencies on other story subtasks that must be completed before a task can be completed.  If a dependency is causing a risk to schedule then it is flagged with an impediment and we can drill in on the dependency as needed.   Our Stories and Subtasks look something like this:

Story - assigned to the Dev Lead or PM

    QA Task: Create Test Cases - assigned to the QA Lead

    Dev/QA: Review Test Cases - assigned to Dev component Lead of the Story

    Dev Task: <Implementation> - assigned to the  Dev component lead of the Story

    Dev Task:<Unit Test> - assigned to the Dev component lead of the Story

    QA Task: Execute Test Cases - assigned to the QA Lead

These subtasks are created automatically when a Story is create.  Then for each sprint the team assigns themselves tasks and provides their original estimates until they are at capacity.  These estimates then rollup to the parent story and rollup to the parent epic which are then burned down during the Sprint.

Hope that helps!

Dan

[Everett Cavazos]

Nice....

[Coby Fuller]

@Dan Graydon interesting approach. Thank you for taking the time to respond.

[Matthew Tsugawa]

It really seems like you're describing a new attribute "primary component". You'd likely want to create a new field to store that value discreetly. It could be obfuscated from the users (hidden on the related transition screen and views) and set by automation rules, but you'd also need to train the users to ensure that they select the 'primary' component first for instance when selecting multiple options in the Component field. Otherwise I don't see how this attribute could be inferred.

[Coby Fuller]

Hmm... interesting idea. I'm going to do some testing around this. Thank you for your response. I will keep you posted with my findings.

[Everett Cavazos]

I don't know if I'm understanding what you're doing exactly, but if you're trying to change assignees based off status, I would suggest just building automation to do that instead.

[Coby Fuller]

To further explain, you can automatically assign an issue during a transition to the Component lead (component development lead) through a workflow post function. The problem that I'm having is that you can also select multiple components for an issue, and when doing so, they are ordered alphabetically. When the post function is triggered, the first Component from the selected alphabetically ordered list of components is used for the assignment. Since the list is ordered alphabetically, the first component in the sorted list is not always the primary component, which means the correct assignee is not selected.

[Curt Holley]

Hi @Coby Fuller 

I agree with @Everett Cavazos you could do this easily with Automation for Jira.

Using In progress as the status and Transformations as the component, it would go like this. There might be a smart value way of getting {{component.Lead}}, but i could find it....at a glance. So the below would mean hard coding the person, rather than referencing the Component Lead.

[Everett Cavazos]

@Coby Fuller I understand now....so you want the assignee to be the component lead of the first component that is chosen in the select list....

It looks like some others have given some good answers, good luck. It's a good question.