Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Control Component Field Ordering

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?

4 answers

1 accepted

2 votes
Answer accepted

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!

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.

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?

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)

Like Coby Fuller likes this

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.

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.

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 Community Leader Jun 30, 2021

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.

auto.png

Like Coby Fuller likes this

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

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.

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.

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

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

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you