Field description matching with math conditions

[Sebastien Pierron]

Hello Everyone, 

I need your help.

I want to implement an automation to direct assign a new ticket when the description is matching values.

Example :

We get ticket from our server :

1 error , 2 warnings, 8 success

When there is "1 or more" error -> Tickets to engineering

When there is "1 or more " warnings -> Tickets to engineering

When there is "0 warnings and errors" -> Ticket do SD

Thanks in advance for your help.

[Mark Segall]

Hi @Sebastien Pierron and welcome to the community!

Can you post a screenshot of a sample issue with this data?  We can likely accomplish this with a regex match, but it would help to have a real use case to make sure I have a full understanding.

[Sebastien Pierron]

Hi Mark. 

Thanks for ur help

Here an example : 

Thanks a lot, 

Regards

[Mark Segall]

Provided your description structure is consistent, this is what I came up with (someone better at RegEx than me may have a better approach):

Explanation

• varResults pulls in that second line of text.

  • {{issue.description.match("^(?:[^\n]*\n){1}([^\n]*)")}}

• varErrors parses the Error count

  • {{varResults.split(" ").get(0)}}

• varWarnings parses the Warning count

  • {{varResults.split(" ").get(2)}}

• If Block is looking for whether the total errors and warnings are greater than 0

  • {{#=}}{{varErrors}}+{{varWarnings}}{{/}}
    greater than
    0

The Assignee blocks are just placeholders, but they should give you a sense of how you can handle routing to Engineering/SD.

[Bill Sheboy]

Hi @Sebastien Pierron -- Welcome to the Atlassian Community!

Adding to Mark's answer with a question...

Do you always have those values (and text values) in the Description field?  For example:

1. What happens when one of the values is zero: the label text (errors warnings successes) are always present, or they are absent when a value is zero?
2. What happens when a value is 1 versus greater than 1: are the label text always plural or are they sometimes singular? (e.g. "error" versus "error")

Kind regards,
Bill

[Sebastien Pierron]

Hello Mark, Bill, 

Hope you had a great week end.

Thanks a lot for your help, to answer ur question Bill, 

1. What happens when one of the values is zero: the label text (errors warnings successes) are always present, or they are absent when a value is zero?

- They stay even when value is null or 0

1. What happens when a value is 1 versus greater than 1: are the label text always plural or are they sometimes singular? (e.g. "error" versus "error")

- They stay plural

Thanks for ur help,

Kind regards,

Sebastien

[Sebastien Pierron]

Hi, 

I tried like this, is it correct ?

[Mark Segall]

This looks right to me.  Is it working for you?

[Bill Sheboy]

Hi!  I suspect that may not work for a couple of reasons...

1) Smart values are name, spacing, and case sensitive.  You defined the variables as {{VarResults}} {{VarWarnings}} and {{VarErrors}} but then sum them in lower case as {{varResults}} {{varWarnings}} and {{varErrors}}  Please try changing one of them so they match case.

2) Created variables are text values, and so to use them as math operands, add asNumber, such as: {{VarWarnings.asNumber}}

[Sebastien Pierron]

Hi, 

Sadly it didn't work this morning.

Do you have any further approach ?

Thanks a lot for ur help

Best Regards, 

Sebastien

[Mark Segall]

Hmm... This worked in my test environment.  Can you share a screenshot of error messages in the audit log?

[Sebastien Pierron]

Hello Mark, 

It just indicates that it passed the issue.

Here some screnshot 

[Mark Segall]

How about this... Let's add an audit log action right after all of the variables with the following:

** {{varResults}} ** {{varWarnings}} ** {{varErrors}} ** {{#=}}{{varErrors}}+{{varWarnings}}{{/}}

This should tell us if the data is being parsed properly.

[Sebastien Pierron]

Hello Mark, 

Thanks again a lot for ur help, 

Still didn't work yesterday, saldy

Print screen here : 

[Mark Segall]

Please see my last comment.  I'd like to add a log action to the rule so we can see if the data is being parsed properly.  Place it right before your If condition

[Bill Sheboy]

Yes, and...the capitalization of the created variables is different and that could lead to mismatch.  They should be the same.  Specifically:

• defined as VarResults but used as varResults
• defined as VarWarnings but used as varWarnings
• defined as VarErrors but used as varErrors

[Sebastien Pierron]

Hello Mark, Bill

Here the full Log : 

Have a nice day, 

Sebastien

[Mark Segall]

As @Bill Sheboy noted, there's a discrepancy in your capitalization of the variable names.  In the variable action you have Var and in the condition your have var.  Try changing those up.   Let's make those changes and see how it goes.

[Sebastien Pierron]

Hello Mark, Bill, 

I changed the capitalization and it's still not working..

I thought about a solution, maybe cut the 3 variable and get them into custom fields ?

Like a field Error, Warning and Success and cut the numbers into those fields ?

Thanks a lot for your help

Best regards, 

Sebastien

[Mark Segall]

You'd still need to parse what comes in over email to populate those fields, unless you plan to do so manually.

Let's not give up on this just yet.  It looks to me like there may be some tweaks to the variables.  Can you do me a favor and create three log entries?  I think one of the variables is not returning anything, causing the error in the log.  Let's try this:

Log Action 1

Warnings: {{varWarnings}}

Log Action 2

Errors: {{varErrors}}

Log Action 3

Warnings + Errors: {{{{#=}}{{varErrors}}+{{varWarnings}}{{/}}

This will help us identify what is not parsing correctly.  It may be a simple tweak to adjust the split parameter on Warnings or Errors.

[Bill Sheboy]

Yes, and...created variables are text and not numbers.  So please also add asNumber to convert them for math operations.  Perhaps like this for Mark's suggested Log Action 3

Warnings + Errors: {{#=}}{{varErrors.asNumber}}+{{varWarnings.asNumber}}{{/}}

[Sebastien Pierron]

Hello Mark, Bill, 

Here is the error message we got this morning, 

Thanks for your help 

[Mark Segall]

Ok - So it looks like there's something off in the parsing.  Can you add another log entry for

Results: {{varResults}}

This will tell us whether (1) regex is pulling the correct line and (2) if it is maybe the splits need to be adjusted for varWarnings/varErrors.

We're getting closer to finding the root cause

[Bill Sheboy]

Yes, and...

I recommend temporarily writing the Description to the audit log just before the variables are created.  That will provide context in the audit log for each rule execution when observing the impact.  Once everything is working, it can be removed.

Another thing to consider: per the automation documentation, the regular expression parsing for rules is based upon the one described in Atlassian's linked documents for Java.  A few times I have encountered some syntax that just does not work with the automation RegEx parser for no clear reason.  A work-around could be to use a much simpler expression to pull out each number, one by one, such as looking for the words error, warnings, and success, and proceeding from there.

[Mark Segall]

Yeah I had run this whole thing through my test environment and it was working perfectly.  I think the issue is that there may be some slight formatting difference between what @Sebastien Pierron shared vs what I manually recreated.  So, hopefully we're really close on this and just need to make a slight tweak.

Agree with @Bill Sheboy that we should log everything while we're trying to troubleshoot.  Good call on that.

[Sebastien Pierron]

@Mark Segall  and @Bill Sheboy 

Once again thank you very much for your help.

Here the screenshot requested

Once again, thanks for ur help

Have a nice eve and week-end

Sebastien

[Bill Sheboy]

Hi @Sebastien Pierron 

For the log message which shows the error, what are you trying to write?  Is it one of these:

Warnings + Errors: {{#=}} {{varErrors}} + {{varWarnings}} {{/}}

or

Warnings + Errors: {{#=}} {{varErrors.asNumber}} + {{varWarnings.asNumber}} {{/}}

Please note my earlier post had too many curly brackets at the front.  Sorry about that!

[Mark Segall]

Yeah this is a really good read-out that shows everything is getting parsed properly.  It's all about the math.  I didn't need the asNumber in my test environment, but agree it should at least be tried here.

[Sebastien Pierron]

@Bill Sheboy @Mark Segall 

I think we are getting close to the solution 

Here are the last logs : 

Have a great Day, 

Best regards, 

Sebastien

[Mark Segall]

I'm not seeing the total in your most recent log. Did you remove that log action?

[Sebastien Pierron]

Oh sorry, here it is : 

[Mark Segall]

Sorry - I meant I don't see it in the log screenshot.  I just want to make sure that for your example, it is in fact totaling up the errors and warnings.

[Bill Sheboy]

Hold on...You are pasting the value in the IF condition as JQL, when that was meant to be logged.  That definitely will not work.

If that was intentional, instead please trying using an advanced compare condition:

• first value: {{#=}} {{varErrors.asNumber}} + {{varWarnings.asNumber}} {{/}}
• condition: greater than
• second value: 0

[Sebastien Pierron]

Hello Bill, Mark, 

I changed it like Bill asked, 

here is the result this morning :

Thanks a lot 

[Mark Segall]

It looks like the format of your Description changed?  The solution was predicated on the Description remaining static. 

Note that the result comes in as:

Last 24 Hours: 0 Errors, 0 Warnings, 4 Successes

Previously it came in as this:

Summary of Last Sessions for all jobs
0 Errors, 0 Warnings, 4 Successes

For this to work, it must be consistent or the parsing will get really complex.

[Sebastien Pierron]

Hi @Mark Segall 

Yes sorry, 

The need changed, now it has to be took from the summary not from the description anymore.

I already change issue.summary

What do i have to change ?

Thanks a lot

Sebastien

[Mark Segall]

So you'll have a couple changes as a result:

• The variable varResults can be removed
• Change varErrors to this:

  • {{issue.summary.split(" ").get(3)}}

• Change varWarnings to this:

  • {{issue.summary.split(" ").get(5)}}

[Alex Koxaras -Relational-]

@Sebastien Pierron did @Mark Segall and @Bill Sheboy answered your question? Please provide feedback since they both put a lot of effort in solving your issue. Thanx!