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

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?

Comments

Nic Brough -Adaptavist-

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?

Everett Cavazos_r5x86r

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.

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)

Matthew Tsugawa_tudxy5

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.

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

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_r5x86r

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

Everett Cavazos_r5x86r

Nice....

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.

Coby Fuller

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

Welcome!

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