Adding a text string to an Epic Name depending on component's text

[Daniel Schoeneck]

Hello all,

I have set up the following 2 automation rules:

1. If in the field Component/s the component name starts with E add #EMP to the Epic name
2. If in the field Component/s the component name starts with F add #FRA to the Epic name.
   
   
   

This works well as long as there is only ONE component selected in the Epic. But if there are 2 components selected, one starting with "E" and one with "F", only #EMP is added to the iEPic name...but I want #EMP and #FRA to be added to the Epic name.

Any idea how to solve this?

[Bill Sheboy · Accepted solution]

Hi @Daniel Schoeneck  and the community helping on this one!

You do not state the format of your epic name, so let's assume it is something like this:

EPICNAME [0 to many component indicators, prefixed by " #"]

Have you considered doing this in one step / edit action (without any conditions), using smart value list filtering? https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588

{{issue.epic name.substringBefore(" #")}}{{#issue.components}}{{#if(equals(name.left(1).toUpperCase(),"E"))}} #EMP{{/}}{{/}}

Please repeat the inner section for any component you want to handle

Also, you would need rules to make the update for different triggering events: issue create, components changed, epic name edited by other than rule, etc.

Kind regards,
Bill

[Mark Segall]

Ha - I should've known that Mr Sheboy would come in with a more elegant approach!  🙂

[Daniel Schoeneck]

Thanky you @Bill Sheboy 
Never thought about that...or let's say: I did not know that this is possible I don't even understand how this code works  and how to implement into my automation rule ;)

What would be the advantage of your solution?

[Wouter van den Berg]

Way cleaner solution definitely. The advantage here is a cleaner solution, less load for automation and no conditions that need matching before execution. 

The disadvantage was made clear the moment you replied. This is definitely more advanced. Upon you leaving the system, the one replacing you will probably have some questions how the logic works.

Thanks for sharing this clean solution @Bill Sheboy

[Bill Sheboy]

Yes, that is a more complicated approach. And...

In my experience, using automation rules requires learning, experimentation, and documentation.  Unfortunately that last one is tricky given current capabilities of rules.  A work-around is to document rules outside of the project, such as in Confluence.  I also save my rules in a test project, and write an explanation in the details so I can remember what I did last week  ;^)  I also add writes to the audit log to explain and assess progress in the rule processing.

Back to Daniel's questions about the suggestion I made...

The first part grabs whatever text in the Epic Name is left of the first Component indicator.  This helps when later updates of the Components field need to refresh the name.  https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#substringBefore-String-separator-

The next part is using the idea of list iterators, {{#someList}}{{someField}}{{/}} to allow walking over the Component values.  This technique is helpful to format things, list a list of issues for an email, or to build up a JSON expression.  https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#Combined-function-examples

And inside that iterator, we are using the newer feature of smart value, list filtering.  This helps to prune the list only to the values you want.  In your case, you wanted to check for specific components' prefix letters.

Finally how to use this: remove all of the condition tests, and a single expression could be used to update the Epic Name field in the Edit Issue action.

[Daniel Schoeneck]

@Bill Sheboy Very nice solution, I want to use it (unless I still don't fully understand it, but that is due to my lack of basic programming knowledge).

I have already created 3 rules that work pretty well using your code:

• Add Squad #hashtag to Epic Name when Epic is created
• Add Squad #hashtag to Epic Name when Component is added later
• Remove Squad #hashtag from Epic Name when Component is removed

But one problem is left:

When there is already a component starting with "F" and I add a second component that start with "F", the hashtag #FRA is added once more. I only need the hashtag once in the Epic Name.

How to prevent it is added once more?

[Bill Sheboy]

First thing, smart value expressions can be built up from simple pieces.  And something what seems like a complicate mess can be explained.  That was a disclaimer for what follows...

Your revised goal is to find the distinct first letters of the component names, and use them to select your tokens/indicators to add to the epic name.  Fortunately smart value lists have a function to return just the distinct values: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.distinct

The challenge is how to get the distinct values and use that in a list filter?  Let's look at this step by step:

1. Let's get just the first characters of the component names as a list with {{issue.components.name.left(1).toUpperCase()}} 
2. We refine that by adding distinct to the end {{issue.components.name.left(1).toUpperCase().distinct}}
3. And because that is a list, it can still be filtered, like this {{#issue.components.name.left(1).toUpperCase().distinct}}{{#if(equals("E"))}} # EMP{{/}}{{/}}

The tricky part is after we got to step #2, these are now just letters in a list, and no longer have anything to do with components.  And so we cannot filter on the "name" attribute any longer. 

Fortunately the iterator and conditional filter logic design is smart enough to compare the list element to the "E".

So your revised template would be this...as now this can happen together:

{{issue.epic name.substringBefore(" #")}}{{#issue.components.name.left(1).toUpperCase().distinct}}{{#if(equals("E"))}} #EMP{{/}}{{#if(equals("F"))}} #FRA{{/}}{{/}}

[Daniel Schoeneck]

Alright, so I need it actually for 3 different types of components

- Starting with E
- Starting with F
- Starting with S

So I tried this code:

{{issue.epic name.substringBefore(" #")}}       {{#issue.components.name.left(1).toUpperCase().distinct}}
   {{#if(equals("E"))}} #EMP{{/}}
   {{#if(equals("F"))}} #FRA{{/}}
   {{#if(equals("S"))}} #STE{{/}}
 {{/}}

But now it just removes all the hashtags from the Epic name. What might be wrong?

With this code it works nicely (except the problem that a hashtag might be added multiple times):
{{issue.epic name.substringBefore(" #")}}
{{#issue.components}}
{{#if(equals(name.left(1).toUpperCase(),"E"))}} #EMP{{/}}                {{#if(equals(name.left(1).toUpperCase(),"F"))}} #FRA{{/}}{{#if(equals(name.left(1).toUpperCase(),"S"))}} #STE{{/}}
{{/}

[Bill Sheboy]

Fascinating...It is not removing them but they are off the field view on the page!  I believe if you click on the field and select all, you will find them off to the right side.

There is something happening due to the use of the stringBefore() function, the iterator, and the extra carriage returns/line feeds you have in the expression.  Please try pasting in this exact one and observe what happens:

{{issue.epic name.substringBefore(" #").trim}}{{#issue.components.name.left(1).toUpperCase().distinct}}{{#if(equals("E"))}} #EMP{{/}}{{#if(equals("F"))}} #FRA{{/}}{{#if(equals("S"))}} #STE{{/}}{{/}}

Please note I added a trim call and removed all extra CR/LF from the expression.

[Daniel Schoeneck]

I tried it, but still the same behavior...
And I also did not find them in the edit mode of the field:

[Bill Sheboy]

I tried this with Jira Cloud, so I wonder if there is a difference as you are using Jira Server, correct?

Let's try writing this to the audit log to see if you see the expected values:

{{#issue.components.name.left(1).toUpperCase().distinct}}{{.}}{{/}}

The result should be the list of just the expected first characters, with comma separators, as a list (not as an array).  If it is an array we can try another work-around with join and split.

[Wouter van den Berg]

I can see your predicament. When there is a lot of changes you don't want to go back in and change the rules each time. Maybe you could extend the solution provided above with a regular expression. I don't remember if Server supports this but I assume it does. Use the branching logic that @Mark Segall provided but instead of component in you could use: 

^[eE] for matching components starting with e or E
^[fF] for matching components starting with f or F

[Wouter van den Berg]

Hi @Daniel Schoeneck

UPDATE: Sorry, didn't see you are on server. I'll leave the answer for the people that end up here using Cloud. 

I have tried a different approach. See screenshot: 

Refetch in the first step might not be needed but I always do it anyways. In my case I did the comment action to see if it works but have a go at this. 

Goodluck. 

[Mark Segall]

Hi @Daniel Schoeneck 

From your screenshots, it appears you're using Jira Server automation, correct?  If so this will be a little more tricky as you don't get the benefit of advanced branching. However, this could be possible and with a single rule.

Can you confirm whether the Epics will ever have more than 2 components?

[Wouter van den Berg]

Ah didn't even notice that. Your approach would be {{issue.components.first.name}} and {{issue.components.last.name}} I presume? 

[Mark Segall]

I was actually thinking more along the lines of 

{{issue.components.name.get(0)}} and {{issue.components.name.get(1)}} but your approach will work too.  🙂

[Daniel Schoeneck]

Hi, 

yes the Epics can have an unlimited number of components

[Mark Segall]

Unfortunately, this makes things more complicated because we're constrained on being able to iterate through the components and components do not work with a wildcard search. 

Are your components constantly changing?  If not, you could go through a one-time pain point of creating two JQL branches:

• BRANCH (JQL)
  For E*
  • Key = {{issue.key}} AND Component IN (E1, E2, E3, E4)
• BRANCH (JQL)
  For F*
  
  • Key = {{issue.key}} AND Component IN (F1, F2, F3, F4)

If the components list changes more frequently, we may be running into limitations of what's possible with Jira Server automation.

[Daniel Schoeneck]

Component names might change frequently yes...
Would it help if we assume that there is a maximum number of components e.g. maximum of 4 components? (in reality 99,9999% of the components will have max. 3 components)

[Daniel Schoeneck]

OH, and yes: there will be more Components be added frequently (E5, E6, ... and F5, F6, ...)

[Daniel Schoeneck]

May be I need a completely different approach?

My ultimate goal is to have "hashtags" on the epics in the epic panel in the Scrum backlog (depending on the selected components in the epics), which allows to use the epic panel filter (which only can filter by the epic name...) 

[Mark Segall]

I think I found an answer to how to handle this:

• IF CONDITION:

  • {{issue.components.name}}
    Contains Regex
    \bE\w+

• ELSE CONDITION:

  • {{issue.components.name}}
    Contains Regex
    \bF\w+

I ran through a few tests in my environment and it seems to be working.

[Wouter van den Berg]

Assuming each components starts with a capital. If you want to cover all options you can use: 

^[eE] for matching components starting with e or E
^[fF] for matching components starting with f or F

[Daniel Schoeneck]

Thank you, I tried like this:

But it still only added #FRA to the Epic name although there is an Component starting with E:

[Wouter van den Berg]

You need to Branch. With If/Else automation will stop once it reaches a succes. 

[Mark Segall]

Good call @Wouter van den Berg 

[Mark Segall]

I would branch into current issue twice and in between the two branches, do a re-fetch

[Wouter van den Berg]

Together we will solve this one @Mark Segall ;) 

@Daniel Schoeneck I saw you are using the Regex Mark has provided. Please make sure you have governance on Component creation. If a user adds a component without capital your rule won't pick this one up as match. The chances users will add a component without capital along the way is very likely if you'd ask me. I have added my solution for this but you are free to use Mark his solution but I still wanted to mention this again. 

[Daniel Schoeneck]

Guys you are genius!

Now I have to make sure that the hashtags will be updated when a component is deleted or added later to the epic. 
I will try myself first ;)